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ABSTRACT 


Recent studies suggest that China is developing a new class of ballistic missiles 
that can be used against moving targets, such as ships. One such technology is anticipated 
to cover a range of 2,000 kilometers and operate at a speed of Mach 10. The threat is also 
capable of maneuvering both during the midcourse and terminal flight phases for the 
purposes of guidance, target acquisition, and countermeasures. This threat could greatly 
impact the current concept of operations of U.S. Navy ships and alter national defense 
policies. While current ballistic missile defense solutions are capable of intercepting 
threats in midcourse and terminal flight phases, no comprehensive system has been 
developed to counter a ballistic missile threat that can (1) maneuver upon reentry in the 
endoatmosphere and (2) be used to attack a moving defended area, such as a U.S. Navy 
carrier strike group (CSG). To fulfill this need, the Anti-Ship Ballistic Missile Defense 
(ASBMD) team conducted research and developed a notional architecture for a system of 
systems solution that could be integrated into the existing Ballistic Missile Defense 
System (BMDS) to effectively counter this threat. This thesis documents the process that 
was used to select and integrate the proposed ASBMD architecture. 
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EXECUTIVE SUMMARY 


Recent studies suggest that China is developing a new class of ballistic missiles 
that can be used against moving targets, such as ships. One such technology is said to be 
able to cover a range of 2,000 kilometers (km) and operate at a speed of Mach 10. The 
threat is also known to possess the capability to maneuver both during the midcourse and 
terminal phases of flight for the purposes of guidance, target acquisition, and 
countermeasures. This type of threat could greatly impact the current concept of 
operations (CONOPS) of United States (U.S.) Navy ships and alter national defense 
policies. The Chinese technology under development includes an anti-ship ballistic 
missile (ASBM) based on a variant of its 1,500 km-plus range DF-21/CSS-5 solid 
propellant medium-range ballistic missile (MRBM). According to the U.S. Department of 
Defense (DoD), if supported by a sophisticated command and control system with 
accurate, real-time target data from China's growing family of terrestrial and space-based 
sensors, ASBMs could pose a significant threat to U.S. Navy carrier strike groups (CSGs) 
in the Western Pacific. ASBMs would offer a variety of operational effects for Chinese 
maritime strategy, particularly with regard to missions involving Taiwan. If this coverage 
is achieved, it could impose significant restrictions on U.S. Naval operations during a 
Taiwan crisis or even hold U.S. theater land bases, such as those on Okinawa, at risk. 

While there are currently ballistic missile defense solutions capable of 
intercepting threats in the midcourse and terminal phases of flight, no comprehensive 
system has been developed to counter a ballistic missile threat that can (1) maneuver 
upon reentry in the endoatmosphere and (2) be used to attack a moving defended area, 
such as a U.S. Navy carrier strike group (CSG). 

To fulfill this need, the Anti-Ship Ballistic Missile Defense (ASBMD) team 
conducted research and developed a notional architecture for a system of systems 
solution that could be integrated into the existing Ballistic Missile Defense System 
(BMDS) to effectively counter this threat. 
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1. INTRODUCTION 


A. PROBLEM DESCRIPTION 

A recent study (Erickson and Yang, 2009) suggests that China is developing 
ballistic missiles that can be used against moving targets, such as ships. One such 
technology is said to be able to cover a range of 2,000 kilometers (km) and operate at a 
speed of Mach 10. The threat is also known to possess the capability to maneuver both 
during the midcourse and terminal phases of flight for the purposes of guidance, target 
acquisition, and countermeasures. This type of threat could greatly impact the current 
concept of operations (CONOPS) of United States (U.S.) Navy ships and alter national 
defense policies. While there are currently ballistic missile defense solutions capable of 
intercepting threats in the midcourse and terminal phases of flight, no comprehensive 
system has been developed to counter a ballistic missile threat that can (1) maneuver 
upon reentry in the endoatmosphere and (2) be used to attack a moving defended area, 
such as a U.S. Navy carrier strike group (CSG). To fulfill this need, the Anti-Ship 
Ballistic Missile Defense (ASBMD) team will propose a notional architecture for a 
system of systems that could be used to effectively counter this threat. 

One example of such a threat is from China, which is pursuing an anti-ship 
ballistic missile (ASBM) based on a variant of its 1,500 km-plus range DF-21/CSS-5 
solid propellant medium-range ballistic missile (MRBM). According to the U.S. 
Department of Defense (DoD), if supported by a sophisticated command and control 
system with accurate, real-time target data from China's growing family of terrestrial and 
space-based sensors, ASBMs could pose a significant threat to U.S. Navy CSGs in the 
Western Pacific. ASBMs would offer a variety of operational effects for Chinese 
maritime strategy, particularly with regard to missions involving Taiwan. If this coverage 
is achieved, it could impose significant restrictions on U.S. Naval operations during a 
Taiwan crisis or even hold U.S. theater land bases, such as those on Okinawa, at risk. 
Two key technical challenges for ASBM development are target acquisition and terminal 
phase guidance; these technical challenges are a result of the strict timing and resource 
constraints that are expected during the terminal phase of ballistic flight. 
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Figure 1 shows the notational maximum ranges of the DF-21/CSS-5 MRBM from 
loeations in mainland China. 



Note: Advertised functional ranges of the Chinese Ballistic Missile arsenal are depicted here. All 
ranges include limitations due to terrain and required flight trajectories (From Erickson and Yang, 
2009). 

Figure 1. Notional Maximum Ranges of DF-21/CSS-5 

Modern ballistie missiles are based on designs that have been used sinee World 
War II. They ean be launehed from land or sea, from either stationary or mobile 
platforms. Ballistie missiles have beeome both the essential long-range artillery of 
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modem warfare and one of the most sueeessful means of exerting international pressure. 
The threat from ballistie missiles has grown steadily as sophistieated missile teehnology 
has become available on a wider scale to countries that are hostile to the U.S. and its 
allies. Figure 2 depicts the proliferation of these types of ballistic missile threats 
worldwide as of 2006. 



Note: Global ballistic missile proliferation has increased steadily in recent decades. Sophisticated 
missile technology is now more widely available to both U.S. allies and hostile nations (From 
Missile Defense Agency (MDA), 2009, April). 

Figure 2. Evolving Security Environment, 2006 
B. BACKGROUND INFORMATION 


The typical ballistic missile uses a rocket engine to give it an initial thrust into the 
air, after which the only force acting on it is gravity to bring it back down to earth. The 
rocket engine consists of some form of fuel and oxidizer, whether solid or liquid based. 
Since ballistic missiles do not depend upon oxygen from the atmosphere, they can spend 
a portion of their flight beyond the earth’s atmosphere. Longer range ballistic missiles 
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spend the majority of their flight in the vacuum of space. Figure 3 depicts the basic stages 
of flight for a nominal ballistic missile. 



Note; Ballistic missile flight timelines can vary by missile type, but any threat classified as 
ballistic follows the same general flight profile (From Missile Defense 101: ICBM Fundamentals, 
2007, May 9). 

Figure 3. Stages of Ballistic Missile Flight 


C. BOOST PHASE 


A ballistic missile’s range depends on the ratio between the thrust generated by its 
engines and the weight that the thrust must overcome. The range of any missile can be 
lengthened by reducing the load that it must carry. If the missile has multiple stages, the 
lower stages will drop off after they have expended their fuel, and therefore, lighten the 
load. At a designated point in space, the last engines shut off or bum out, which ends the 
boost phase of the missile’s trajectory. The time between launch and engine burn out can 
range from less than one minute to over five minutes. From this point on, the laws of 
physics will carry what remains of the missile, as well as the payload, to the vicinity of 
the target. 
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1. Midcourse Phase 


The second phase of flight for a ballistic missile is the midcourse phase. As the 
missile reaches apogee, the section that carries the payload, called the post-boost vehicle, 
makes final adjustments to the missile’s course. During this time, missiles that carry 
multiple warheads eject each warhead precisely in the direction of its individual target. 
They can also deploy countermeasures, such as decoys, to give false targets to enemy 
radars. Some post-boost vehicles are designed to release a number of small submunitions 
or lethal chemical/biological compounds instead of warheads and decoys. As warheads or 
reentry vehicles, decoys, and the remains of the missile coast over the top of the ballistic 
arc, and until they reach the upper edges of the atmosphere above the target, they fall 
freely. As they do so, these items gradually spread apart along their individual ballistic 
paths. They reach maximum speed at the end of the midcourse phase, before the 
atmospheric interference associated with reentry begins. 

2. Terminal Phase 

The final phase of flight for a ballistic missile is the terminal phase, which begins 
as the missile reenters the endoatmosphere. At this time, air molecules begin to slow, 
heat, and bum up any decoys and the remains of the post-boost vehicle. The warhead or 
reentry vehicle is hardened against heat and pressure and designed to enter the 
endoatmosphere with minimal damage. The range of the missile determines the angle at 
which the vehicle or warheads fall onto the target. Warheads from the longest range 
missiles arrive at shallow angles of little more than 20 degrees, while shorter range 
deliveries can impact at 45 degrees. 

Typically, the warhead of a ballistic missile consists of single or multiple reentry 
vehicles. These reentry vehicles are free-falling, i.e., they have no independent 
mechanism that will direct them to their intended target. Their accuracy is dependent on 
the calculations made before launch, sometimes with minor course corrections being 
allowed during the midcourse phase of flight. The unique characteristic of the ASBM 
threat is that it will employ a maneuvering reentry vehicle. These reentry vehicles should 
be able to calculate course corrections and re-direct themselves to the intended target. 
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such as a ship that has changed position since the time that the threat missile was 
launehed. Figure 4 depiets a notional ballistie missile trajeetory with the addition of a 
maneuvering reentry vehiele. 



launch site 


carrier when the 
missile was launched) 


of the aircraft 
carrier with mid 
segment guidance) 


D 

Target point 
(current location 
of aircraft carrier) 


Note: Recent threat analysis has determined that multiple countries have created and tested a new 
class of ballistic missile that has the ability to maneuver during the terminal phase of ballistic 
flight for the purpose of striking moving targets, such as ships. Defense against terminal 
maneuvers represents a capabilities gap in existing combat systems (From Erickson and Yang, 
2009). 

Figure 4. Notional ASBM Trajectory with Maneuvering Reentry Vehicle 
D. PROJECT DESCRIPTION 

The objective of the proposed ASBMD System is to detect, track, and eliminate 
ASBM threats. The objective of the ASBMD team was to conduct research and document 
a proposed architecture for a system of systems solution that could be implemented to 
combat the evolving ASBM threat. The team has investigated and documented potential 
solutions to address this threat, while ensuring that currently fielded capabilities are not 
degraded. 


The scope of this Capstone Project includes the research, creation, and 
documentation of the total system architecture that may be used to combat the identified 
ASBM threats. The following constraints were identified to bound the system that the 
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team created. These constraints ensured that the team focused the requirements and 
functionality of the system to address the specific problem statement: 

• ASBM threats will be launched from land. 

• All current communication mechanisms required for conduct of the ASBMD 
mission are operational and deployed on all participating systems. 

• The ASBMD System will be used for Ballistic Missile Defense (BMD) only. 

• The ASBMD System will be integrated into and communicate with the 
existing BMD System (BMDS). 

• The ASBMD System will not degrade the existing BMD network. 

• The ASBMD System design will comply with all applicable U.S. military 
and/or commercial specifications and standards. 

E. SYSTEM ENGINEERING APPROACH 

This project will focus on the Materiel Solution Analysis phase of the Defense 
Acquisition Management System, using Department of Defense Instruction 
(DoDI) 5000.02 (2008, December 8) as the guide. The ASBMD team has created high- 
level prototypes of several key documents identified in the Integrated Defense 
Acquisition, Technology, and Logistics (AT&L) Life Cycle Management Evolutionary 
Acquisition Program. Figure 5 depicts the high-level view of the Defense Acquisition 
Management System, with the area addressed by this project shown in yellow. 
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Note: Application of the Defense Acquisition Management System process is key to ensuring that 
all aspects of program acquisition and lifecycle management are followed throughout system 
development and fielding (From DoDI 5000.02, 2008, December 8). 

Figure 5. ASBMD Focus within the Defense Acquisition Management Process 

The ASBMD team has chosen to follow the “V” model version of the Systems 
Engineering Process (SEP). A representation of the “V” model for the Materiel Solution 
Analysis phase is provided in the Integrated Defense Acquisition, Technology, and 
Eogistics Eife Cycle Management Chart (Defense Acquisition University, 2009, 

June 15). The ASBMD team adapted this “V” model for use in ASBMD project 
development as shown in Eigure 6. The “V” model approach provides a detailed 
framework and development guideline that enabled the team to analyze this capability 
gap from a top-down perspective. The “V” model is constructed to enable each document 
or analysis effort to build upon the previous effort, which ensured continuity throughout 
the project. The “V” model approach also contains continuous feedback loops during all 
stages of analysis and development, which ensured that analysis and research results were 
incorporated into the previous documentation. The team tailored the model to work 
within the limited scope and time allocated for the project; the team chose the specific 
documentation and artifacts that would provide the most benefit to the project and those 
that were prerequisites for the next phase of research. The team also chose to limit the 
scope of some of the documents. These limited-scope documents were designed as 
excerpts, indicating that the document contained only the sections that the team thought 
were required to allow the project to progress. The artifacts that were identified as 


8 

























required deliverables are detailed in the following chapters and are listed in section F 
below. 



Note; The “V” model process is used to ensure that each artifact is created from a top-down 
perspective, ensuring a complete and robust system solution that is fully traceable through the 
system engineering process (Adapted from Defense Acquisition University, 2009, June 15). 

Figure 6. Tailored Materiel Solution Analysis “V” Model 
F. DELIVERABLES 

The ASBMD team provided the following products for this Capstone project as 
individual deliverables, which are excerpted in this report: 


• Problem Statement: Outlines the current system capabilities and threat 
assessments; this provides details of the current system functional gap. 

• Project Management Plan (PMP) (Appendix A): Details the approach and 
schedule for developing the project documentation. 
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• CONOPS (Appendix B): Describes the project CONOPS and initial plan for 
integration of the solution into existing systems. 

• Functional Area Analysis: Identifies operational tasks, conditions, and 
standards needed to accomplish the system objectives. 

• Functional Architecture (DoD Architecture Framework (DoDAF) products): 
Depicts the overall system alignment and functions from a high-level system 
view; these detail interactions within the system and identify the key functions 
that are performed. 

• Initial Capabilities Document (ICD) (Appendix C): Identifies the Key 
Performance Parameters (KPP) and Key System Attributes (KSA) (defined in 
the Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 3I70.0IG, Joint 
Capabilities Integration and Development System (JCIDS) (2009, March 1)), 
which define the most critical system performance elements. This document is 
closely tied to the CONOPS to ensure that the KPPs identified meet the 
overall need of the system as originally defined during the analysis phase. 

• Analysis of Alternatives (AoA) Results: Details the results of the evaluation 
of each possible system alternative. This analysis documents the ability of the 
alternatives to meet KPPs and KSAs, as well as affordability and schedule 
constraints. 

• Metrics, Models, and Simulation Analysis: Details the models and 
associated metrics used to validate the performance of the chosen system to 
ensure that it meets the established Measures of Effectiveness (MOEs), 
Measures of Performance (MOPs), and KPPs. 
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II. SYSTEM ANALYSIS 


A. OVERVIEW 

This chapter describes the artifacts and analyses that the team created during the 
functional system analysis of conceptual system architectures. The following sections 
detail the process that was followed as the team derived high-level requirements from 
stakeholder inputs and decomposed those system requirements into the functional 
components of the system. 

B. STAKEHOLDER ANALYSIS 

To ensure that the system engineering process was applied in a manner that would 
yield a solution to thoroughly address the needs statement and fill the identified 
capability gap, the team obtained inputs from interested stakeholders. The stakeholders 
were identified as persons who could provide insight about technology needs from the 
fleet, program office, and end user perspectives. Inputs from these individuals were 
obtained via meetings, briefings, and surveys. Their insight was used to frame the 
analysis products and was also captured in the weighting of needs that was applied during 
the Functional System Analysis (FSA). 

C. FUNCTIONAL SYSTEM ANALYSIS 

An FSA is the process that the team used to derive the key functional artifacts 
required to build the notional ASBMD architecture candidates. This analysis began with 
a high-level initial needs statement that was similar to the problem statement that the 
team developed during the initial stages of the project. The next step in the process was to 
create the operational documentation that would help bound the system; this operational 
documentation consisted of the CONOPS and Design Reference Missions (DRMs). 

Using the operational documentation, the team was able to derive high-level system 
requirements and MOEs/MOPs and perform functional allocation, as well as create 
functional flow diagrams that detail the interactions of the system. Each step of the ESA 
process is detailed in the following sections of this chapter. 
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Figure 7 depicts the requirements generation process flow used to ensure the 
alignment of the system with the needs statement. 



Note; Flow of requirements generation is key to ensuring that the final 
product meets stakeholder needs and operational/functional requirements. 

Figure 7. ASBMD Requirements Generation Process 
1. Concept of Operations 
a. Purpose 

The primary function of the ASBMD CONOPS document was to identify the 
scope of work for the investigation and documentation of a system architecture that could 
be used to implement a system to defend against ASBM threats. It detailed the 
operational needs and mission requirements for such a system. It also discussed potential 
gaps in the current systems being used to detect, track, and eliminate the latest ballistic 
missile and ASBM threats. 


The ability to detect, track, and eliminate the identified ASBM threat will require, 
at a minimum, upgrades to existing systems. The primary goal of the team was to 
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perform detailed analyses to determine the most robust system of systems to perform the 
full detect-to-engage sequence. To achieve this goal, the team would investigate both the 
use of existing systems and the development of new technologies, as appropriate, to 
fulfill all required functions. 

Due to the maturity of existing capabilities to detect and track ballistic missiles 
during the boost phase, the ASBMD team focused the detailed analysis and architecture 
documentation on the post-boost phases of flight: tracking and eliminating the threats 
during later phases of the ballistic flight-path. Refer to Figure 3 for a graphical 
representation of a ballistic missile trajectory and its stages. 

b. Threat Analysis of the Ballistic Missile Trajectory 

Intercepting a missile in its boost phase is an ideal solution for BMD. If the 
missile is carrying a chemical, biological, or nuclear weapon, the debris would most 
likely fall on the country that launched the missile. At this altitude, the threat would not 
have obtained enough velocity to reach its intended target, eliminating the need to 
completely destroy the threat missile’s warhead. Although attacking a missile while it is 
struggling against the earth’s gravity is ideal, it poses several significant challenges to a 
defense system. First, the boost phase is relatively short, limiting the amount of time that 
sensors will have to detect a launch and relay accurate information about the missile. 
Second, an interceptor missile would have to be very close or extremely fast to intercept 
the accelerating missile and properly configured to intercept a target in the boost phase. 
When possible, for the global coverage and protection against more lethal payloads that it 
can provide, a capability to intercept a missile near its launch point is always preferable 
to attempting to intercept that same missile closer to its target. 

The midcourse phase allows the largest opportunity to intercept an incoming 
missile. At this point, the missile has stopped thrusting, and it follows a more predictable 
path. Depending on the interceptor launch location, multiple interceptors could be 
launched with a delay between them to determine if the initial attempts were successful. 
Due to the increased engagement timeline, fewer interceptor sites are needed to defend 
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larger areas. A longer period in space provides an attacking missile the opportunity to 
deploy countermeasures against a defensive system, if equipped to do so, but the 
defensive system also has more time to observe and discriminate countermeasures from 
the warhead. 

The terminal phase of ballistic missile flight is normally less than one minute in 
duration. At this point, defensive systems must be very close to the threat missile’s target 
in order to defend against the attack. Countermeasures are less of a challenge in this 
phase, as they usually fall at a slower rate than the warhead or are burned up as they 
reenter the atmosphere. Defensive systems designed for the terminal phase are most 
effective in protecting nearby troop concentrations, ports, airfields, and staging areas. 
Currently fielded terminal phase interceptors have not been proven effective against 
maneuvering reentry vehicles. More information is provided in the next section about 
current capabilities the U.S. has to counter ballistic threats. 

c. Existing Capabilities to Address the Threat 

Multiple systems are currently deployed as part of the BMDS that are designed to 
combat ballistic missile threats. Each individual system is designed to focus on specific 
phases of the ballistic missile trajectory. When integrated within the BMDS, these 
systems provide a layered defense capability. Some examples of these systems and their 
primary functions are provided in Table 1. 
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Table 1. Existing BMD Systems 

Note: The existing BMDS is a layered network comprised of a variety of systems and 
technologies. These systems provide BMD coverage in a variety of scenarios and ranges for a 
multitude of ballistic missile threats. 



System Name 

Phase 

Function 

Weapon 

Systems 

Kinetic Energy Interceptor (KEI) 

Boost 

Intercept 

Airborne Laser (ABL) 

Boost 

Intercept 


Ground-Based Interceptor (GBI) 

Midcourse 

Intercept 


Standard Missile (SM)-3 Block lA 

Midcourse 

Intercept 


Patriot Advanced Capability-3 (PAC-3) 

Terminal 

Intercept 


SM-2 Block IVA (SM-T) 

Terminal 

Intercept 


Terminal High Altitude Area Defense 
(THAAD) 

Terminal 

Intercept 


Arrow Weapon System 

Terminal 

Intercept 

Sensors 

Cobra Dane Radar 

Boost/Midcourse 

Detection/Tracking 


Cobra Judy Radar 

Boost/Midcourse 

Detection/Tracking 


Upgraded Early Warning Radar (UEWR) 

Boost/Midcourse 

Detection/Tracking 


AN/TPY-2 (Forward-Based Mode) 

Boost/Midcourse 

Detection/Tracking 


Sea-Based X-Band Radar (SBX) 

Midcourse 

Detection/Tracking 


AN/SPY-1 

Midcourse/Terminal 

Detection/Tracking 


AN/TPY-2 (THAAD Mode) 

Terminal 

Detection/Tracking 


Green Pine Radar 

Terminal 

Detection/Tracking 


PAC-3 Radar 

Terminal 

Detection/Tracking 


Space Tracking and Surveillance System 
(STSS) 

All 

Detection/Tracking 


Space-Based Infrared System (SBIRS) 

All 

Detection/Tracking 


The Aegis BMD System is an example of a successful BMD system. This system 
uses both remote and local detection/tracking via ground and satellite-based sensor 
systems, as well as shipboard sensors. Once an external network sensor detects a threat 
and transitions it to a radar track, the remote systems can “hand over” the threat track to 
the shipboard AN/SPY-1 radar for organic (ownship) tracking and engagement. The 
handover of the threat track is accomplished by having the remote tracking system 
calculate a flight trajectory of the threat track and then cue the organic radar to a point in 
space where the threat will be at a given time. This method requires direct, high-speed 


15 

























communication between all elements in the system. The Aegis BMD system also relies 
heavily on the availability of the Standard Missile (SM)-3 or SM-2-Blook IV missile to 
engage and destroy ballistie targets in the mideourse and terminal phases, respectively. 
These systems eurrently have no alternate or eomplementary shipboard weapons that 
could be used to combat a ballistic threat. Figure 8 is a pictorial representation of the 
Missile Defense Agency’s BMDS, which includes the Aegis BMD system. 



Ground-Based Fire 
Control Suite 


Cobra 
Dane Radar 


Sea-Based 

X-Band 

Radar 


Beale | 
Radar 


U.S. Northern 
Command 
Fixe Control Suite 


Ground-Based 
Interreptors (3) 




Ground-Based 
Interceptors (20) 




UK Situational 
Awareness 
Node 


Fylingdales 

Radar 


Aegis 

Sufveillsnce i 
Track 
Destroyers 

(7) 


Forward-Based X-Band 
Radar-Transportable ^ 


U.S. Pacific'5=* 
Command 


i -'ib 

Ae|u Engagement Cniisen (3) 
Aem Ensagement Destroyen (7) 
Staimard Misfile-3 Interceptors (21) 


National Capital 
Region 


Patriot PAC-3 Batteries 


None Of This BMD Capability Existed In June 2004 


Note; Existing U.S. BMD assets as of 2007 are shown. The emerging ballistic missile threat has 
created an urgent need for a shift in U.S. policy to dedicate resources to the acquisition and 
fielding of BMD network assets (From Sanders, 2007, June 28). 

Figure 8. Pictorial Representation of the MDA BMDS 

Multiple systems are currently deployed or in development that have the ability to 
detect and track ballistic missiles during boost, midcourse, and terminal phases. Coupled 
with the existing system that provides the capability to engage these threats during all 
ballistic phases, the U.S. has a robust system design that has a successful track record 
during test intercepts of ballistic targets. 


d. Shortcomings of Current Systems 

As previously described, the current BMD systems rely heavily on the ability of 
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remote, internal, and on-board sensors to predict and relay the flight path trajectory of the 
ballistic threat. The anti-ship threats that are being introduced have been designed to 
exploit limitations in the current deployed capabilities. Using the example threat given in 
the problem statement, the threat can be traveling in excess of Mach 10 at the time of 
reentry and can maneuver during the terminal portion of flight, altering its aimpoint and 
ultimately forcing a defense system to estimate a false trajectory. Given the current 
capabilities, the ability of the system to predict the ultimate flight path of these threats 
becomes impossible. 

Another shortcoming of the current systems is that, for sea-based intercepts, they 
rely exclusively on the availability of ships configured with the Aegis BMD Weapon 
System and loaded with SM-3 or SM-2-Block IV missiles. Only 3 cruisers and 
15 destroyers are configured to conduct Aegis BMD missions as of 2009, so these assets 
must be strategically located to provide adequate coverage. While the SM-3 Block lA is a 
full-rate production missile, it is only capable of conducting midcourse intercepts. The 
Sea-Based Terminal (SBT) terminal-phase intercept capability is provided by use of the 
modified SM-2 Block IV, also known as the SM-T missile. The modifications that were 
made to the SM-2 Block IV to achieve the SBT capability transformed the weapon from 
an Anti-Air Warfare (AAW) interceptor to a BMD interceptor. These changes enabled 
the missile to intercept high-velocity ballistic threats in the last moments of their flight. 
The SM-T missile is no longer in production, constraining the SBT capability to the 
remaining inventory in the near term. A far-term SBT capability using a different missile 
is under development, but will not be fielded for several years. Given the minimal system 
availability, a significant operational risk exists for most CSGs when operating within the 
expected range of ASBM threats. 

Based on the capabilities deployed to date, if ASBM threats are put into full-rate 
production, a fundamental shift would be needed in the current operational CONOPS for 
the U.S. Navy. Without a robust and reliable system to counter these threats, U.S. Navy 
CSGs would be required to drastically reduce their ability to operate within close vicinity 
of countries that have the threat production capabilities. 
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e. Priority of New Features 

The ASBMD System will perform the detection-through-engagement portion of 
the sequence for an ASBM threat. The specific benefits of the ASBMD System will be its 
ability to track and eliminate or avoid maneuvering threats during the midcourse or 
terminal phases of flight. The Navy will benefit from a robust architecture that can 
provide engagement-quality data to a system that can be used to eliminate the threat 
during the later phases of flight. 

The ASBMD team has prioritized the key system features, taking into 
consideration existing systems that can perform portions of the mission. As stated earlier, 
multiple systems are being developed that have the ability to detect and engage ballistic 
missiles during both the boost and midcourse phases of ballistic missile flight; therefore, 
the priority of the proposed system and analysis is the tracking and engagement of ASBM 
threats during the post-boost phases of flight. Specifically, the team has prioritized 
engagement of the threat during the midcourse phase of flight as the highest priority of 
the proposed system; a midcourse intercept would eliminate the threat before it can 
conduct its maneuver. 

For operations within the terminal phase of flight, there are two key system 
functions—tracking and engagement—that have also been prioritized for assessment. The 
ASBMD team prioritized tracking of the reentry vehicles as the highest priority, and then 
the engagement of the threats as the second highest. The ASBMD System is dependent 
on the ability of the system to provide engagement quality data to engage and eliminate 
the threats; therefore, accurate tracking of the threats is of the utmost importance. 

f. Functional Analysis Results 

The ASBMD capability will be achieved by a system of systems that, to meet its 
mission requirements, is comprised of a minimum set of components. Components 
considered and analyzed included: radar, electro-optic (EO)/infrared (IR) sensors, passive 
electronic warfare sensors, communications/link architecture, command and control 
systems, decoys, electronic countermeasures, and one or more weapon systems. 
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A preliminary functional analysis resulted in a list of the primary system 
functions, as follows: 

• Search: The system will be capable of conducting search functions in 
self-defense and BMD modes. 

• Detect: The system will be capable of detecting an incoming threat 
organically (using ownship sensors). The system will also be capable of 
initiating engagement sequences based on remote sensor detection and 
track hand-off. 

• Acquire Track: The system will be capable of conducting organic track 
acquisition and communicating that track to the BMDS. The system will also 
be capable of launching on remote track data (with eventual acquisition of the 
track organically) or full engagement on remote track data (with no organic 
track acquisition). 

• Planning: The system will be capable of communicating with BMDS 
resources for determination of the best use of local radar and weapon 
resources. 

• Identification: The system will be capable of identifying the threat type via 
on-board sensor discrimination and will not engage on countermeasures. 

• Engagement: The system will be capable of executing an engagement against 
the incoming threat. 

• Kill Assessment (KA): The system will provide KA data to the operator and 
the BMDS so that a determination of kill and the potential for reengagement 
can be assessed. 

The system must be capable of surviving and operating in the tactical 
environment and will meet all requirements for system certification and fielding. Ships 
with this capability can be deployed in any operational area necessary to provide 
coverage in the ASBMD mission area. The system, as designed, must interface with the 
larger BMDS for the purposes of battle management and command and control. It will 
interface with its battlegroup or ships-in-company for local fire control, radar resource, 
and weapon management. 
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Currently, there is no single solution to address the ASBM threat. In designing a 
system-of-systems solution, a key objective of this project was to consider technologies 
that would complement a layered approach that takes advantage of remote and forward- 
based capabilities as well as organic/ownship capabilities. Any leveraging of existing 
technology will require that the systems are made more robust to meet requirements for 
sensor function, detection, and BMDS interfaces. The final aim of the system design is to 
propose a reliable, compatible, and interoperable ASBMD functionality to support 
defense of critical assets and mission areas to the Navy. 

2. Design Reference Mission Profiles and Scenarios 

a. Purpose 

As defined by Pace (2000), a DRM defines the specific projected threat and 
baseline operating environment for a given system; these may range from a single¬ 
purpose weapon system to a multi-mission platform, or to a multi-system, multi-platform 
system of systems. The ASBMD DRM provides a notional description of deployed 
operations for the mission as described in the ASBMD CONOPS. It is primarily an 
engineering/design tool used to support systems engineering activities by identifying 
significant, design-driving operational elements and characterizing them to the level of 
detail necessary to assess their design impact. The DRM is intentionally modular to allow 
the team to tailor or modify the scenario and its components over time in order to update 
operational and warfighting requirements and prospective solutions. To this end, the 
DRM is envisioned as an evolutionary document that can be revised throughout the 
acquisition process. The DRM is comprised of two distinct components: Design 
Reference Mission Profiles (DRMP) and Design Reference Mission Scenarios (DRMS); 
each component will be detailed in the following sections. 

b. DRM Profiles 

The DRMP is a matrix of the best, expected, and worst values for each of the 
operational conditions for the ASBMD system. The DRMP helped bound the operational 
capabilities of the system by defining the overall timing requirement for each of the sub¬ 
functions of the ASBMD system. 
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The example DRMP is shown below in Table 2. 


Table 2. DRMP for the ASBMD System 


Note; The DRMP is a matrix of the best, expected, and worst values for each of the operational 
conditions to which the concept architecture will be exposed. The DRMP helps to ensure that the 
system requirements cover the operational context of the system. 


Event 

Required 

Equipment 

Factors 

Condition 

Best 

Expected 

Worst 

Missile Launch 

N/A 

# of Missiles 

1 

2 

4 

# of Locations 

1 

1 

2 

Missile Detection 

Organic/Nonorganic 
Detection System 

Time to Detect 

1s 

10s 

No 

Detection 

Ship Time to 
Detect 

Is 

20s 

No 

Detection 

Missile Tracking 

Organic/Nonorganic 
Tracking System 

# of Missiles 

1 

2 

6 

Compute Fire 
Control Solution 

Organic/Nonorganic 

System 

Time to Compute 

Is 

3s 

10s 

Transmit 

Kill Order 

Communication 

Network 

Time to Transmit 

Is 

5s 

10s 

Missile 

Engagement 

Participating Units 

Weapons 

Available 

5 

3 

1 

Missile 

Kill Assessment 

BDA Capable 

System 

Operational 

Yes 

Yes 

No 

Missile 

Re-Engagement 

Participating Units 

Weapons 

Available 

Yes 

Yes 

No 


c. DRM Scenarios 

The DRMS are graphical representations of the DRMP criteria. The DRMS that 
the team created, along with the general explanation of each, are shown below. 

The best scenario in DRM terms is one in which the ideal conditions for operation 
of the system are present. For ASBMD, the best case scenario consists of the following 
conditions: 


• A single threat is launched from a known launch site. 

• All participating defense systems/units are online and fully operational. 
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Environmental factors do not impact performance. 




Figure 9 depicts the best case scenario for the ASBMD system. 



Note: The best case DRMS represents the minimal threat environment that the system will 
encounter. Using the best case DRMS will help bound the minimum capability required of a 
system in the optimal environment. 

Figure 9. DRMS 1 (Best) for ASBMD 

The expected scenario is depicts the conditions that the ASBMD System is most 
likely to encounter in the tactical environment. Conditions in this scenario are neither 
ideal nor dire. The conditions for the expected scenario are as follows: 

• Multiple incoming threats are launched from one launch site. 

• Satellite coverage is provided for one launch site. 

• The CSG experiences average environmental conditions and their associated 
performance impacts. 

• Three defense units are participating: Satellite, Forward-Based Sensor, and 
Firing Ship. 
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Figure 10 depicts this scenario. 



Note: The expected case DRMS represents the nominal threat environment that the system will 
encounter. This scenario is used to derive the objective values for many of the system performance 
requirements. 

Figure 10. DRMS 2 (Expected) for ASBMD 

The worst case scenario is a depiction of the worst operational environment that 
the ASBMD System is expected to encounter. The conditions for this scenario are as 
follows: 

• Multiple incoming threats are launched from multiple launch sites. 

• Participating units experience performance degradation due to adverse 
environmental conditions. 

• Detection and tracking of threats is unreliable. 
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Figure 11 shows this scenario for ASBMD. 



Note: The worst case DRMS represents the most taxing threat environment that the system will 
face. This scenario is used to determine the upper bounds of the system capabilities, including 
bounding values for computer processing and network loading requirements. 

Figure 11. DRMS 3 (Worst) for ASBMD 
3. Initial Capabilities Document 

a. Purpose 

The primary function of the ASBMD ICD, provided as Appendix C, was to 
describe the need for a material approach to fill the functional gap within the current 
BMDS that is created when ASBM threats are introduced into the arsenals of enemy 
combatants. This document defines the existing capability gap in terms of the functional 
areas affected and also describes why non-material changes alone are not adequate to 
fully provide the needed capability. 

b. Functional Requirements 

The following is a list of high-level functional requirements that was used as the 
basis for the follow-on system analysis and decomposition. It is an excerpted list of 
requirements provided as part of the ICD, and should not be viewed as a complete list of 
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requirements that the system must meet. 


• The ASBMD System shall be capable of sending, receiving, and processing 
intelligence reporting messages to be used for situational awareness related to 
ballistic missile flight path. (This includes, but is not limited to, the ability to 
receive and process Global Command and Control System Maritime 
(GCCSM), Tactical Data Link (TDL) (Link-11, Link-16), and Data 
Distribution System (DDS) messages.) 

• The ASBMD System shall process received intelligence messages and create 
radar search sectors to be used by both on-board and off-board sensors. 

• The ASBMD System shall be capable of tracking no less than 10 vehicles 
during the midcourse and/or terminal phases of missile flight path. Tracking 
shall include the production and dissemination of engagement quality data. 

• The ASBMD System shall be capable of near simultaneous engagement of no 
less than two ballistic vehicles. 

• The ASBMD System shall be capable of performing Launch on Remote 
(LoR) using fire control quality data from the BMDS network. 

• The ASBMD System shall be compatible with the ship’s requirement and 
capability to perform both self-defense (i.e., AAW) and BMD missions. 

• The ASBMD System shall have a Mean Time Between Failures (MTBF) that 
is greater than or equal to the MTBF of the existing BMDS architecture into 
which the ASBMD System will be integrated. 

• The ASBMD System shall have the ability to perform high fidelity object 
discrimination. 

• The ASBMD System shall have the ability to perform localization. 

• The ASBMD System shall have the capability to perform threat identification. 

c. Measures of Effectiveness and Measures of Performance 

MOEs and MOPs are quantitative measures that give some insight into how 
effectively a unit must perform under the operational conditions defined in the CONOPS 

and detailed in the DRMs. The MOEs for this project were defined primarily through the 
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use of stakeholder inputs, as described earlier in this chapter. The ASBMD team defined 
the MOPs using the nominal values that were obtained during the initial investigation and 
analysis portion of the project. The key ASBMD System MOEs and MOPs are identified 
in Tables 3 and 4, respectively. As with the system requirements, these lists should not be 
considered complete, as they are excerpts from the documents that were used to help 
bound the system. 


Table 3. ASBMD MOEs 


Note: MOEs are defined by stakeholder inputs. They are used to measure the ability of the concept 
architectures to meet the operation needs of the overall system. 


MOE 

Description 

Objective 

Pd 

Probability of detection 

0.95 

Pf 

Probability of false alarm 

0.005 

Pkhi 

Probability of kill 

0.97 

Pid 

Probability of correct identification 

0.9997 

P dis 

Probability of correct discrimination 

0.9997 

MaxTgteng 

Maximum number of targets engaged 

2.0 

P info 

Probability of information exchanged 

0.9999 

MaxTgttrk 

Maximum number of targets simultaneously tracked 

10.0 


Table 4. ASBMD MOPs 


Note: MOPs are defined by stakeholder inputs. They are used to provide a measurement of the 
ability of the system to perform in a system of systems context. 


MOP 

Description 

Objective 

Trk 

Track formulation time 

0.5 sec 

Tdet 

Organic detection time 

6 sec 

Teng 

Engagement time 

60 sec 

Te-eng 

Re-engagement time 

15 sec 

Tkiii 

Time to conduct kill assessment 

10 sec 

Neng 

Number of simultaneous engagements 

2 
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4. Functional Analysis and Allocation 

Functional Analysis is the process by which the team took the identified key 
system requirements {How's) and the need statements (What's) and combined them into a 
Quality Function Deployment (QFD) matrix. Each need statement was weighted by using 
the inputs solicited during the stakeholder analysis portion of the project. Next, the 
requirements were rated against the needs statements; each requirement was assigned a 
numerical rating between one and ten that corresponds to the level of influence that it has 
in fulfilling the identified needs. The mapping of requirements to mission needs is 
depicted in Table 5. The team used this process to assist in the allocation of requirements 
to the identified functions of the system. Each function will be detailed in the following 
sections of this document and is depicted in Table 6. 


27 



Table 5. Functional Analysis 


Note: Functional Analysis ensures that each identified functional requirement is mapped to an 
identified need. Each need is weighted to help drive the functional prioritization of the system. 


Functional Analysis 


Needs 

(What’s) 

Weights 

Requirements (How’s) 

Capable of 
processing 
received 
intelligence 
messages 
and creating 
radar search 
sectors for 
use by on¬ 
board and 
off-board 
sensors 

Capable of 
performing 
launch on 
remote using 
fire control 
quality data 
from the 
BMDS 
network 

Capable of 
performing 
both self- 
defense and 
BMD 
missions 

Capable of 
an MTBF that 
is greater 
than or equal 
to the MTBF 
of the 
existing 

BMDS 

Capable of 

sending, 

receiving and 

processing 

intelligence 

reporting 

messages to 

be used for 

situational 

awareness 

Capable of 
near 

simultaneous 
engagement 
of no-less- 
than two 
ballistic 
vehicles 

Protect other 
assets from 
ballistic missiles 

0.275 

8 

7 

8 

5 

8 

9 

Interoperable with 
BMDS 

0.15 

9 

8 

4 

5 

9 

3 

Stand-alone BMD 
capability 

0.15 

3 

3 

9 

3 

3 

9 

Destroy ballistic 
missiles with a 
high probability of 
kill 

0.275 

7 

7 

9 

5 

6 

9 

Operate across a 
wide range of 
environmental 
conditions 

0.15 

5 

5 

7 

8 

9 

7 

Sum 1 



Weighted 

Performance 

16.4 

16.0 

20.6 

16.0 

19.4 

20.7 

109.1 

Percentage 

0.151 

0.147 

0.189 

0.147 

0.178 

0.190 
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Table 6. Functional Allocation 


Note; Functional Allocation is the mapping of system functions to the known components of the 
functional architecture. This mapping ensures that the system under analysis is sufficiently 
bounded and that there is no unintentional overlap of functions. 


Components 

Functions 

Nonorganic 

Assets 

Organic 

Radar 

Fire 

Controi 

System 

Data 

Transfer 

System 

BMDS 

Receive/Transmit Intelligence Cueing 




X 


Detection 

X 

X 




Classification 

X 

X 




Tracking 

X 

X 




Discrimination 

X 

X 




Identification 


X 




Decide and Assess 

X 




X 

Engage Ballistic Missile 



X 



Perform Kill Assessment 

X 


X 




5. Functional Flow Diagrams 

The proposed ASBMD System is scoped as a system of systems that provides a 
set of value-added functions within the existing BMDS. The system’s objective is to 
provide increased capabilities to defend against and eliminate ASBM threats. The 
proposed system will be fully integrated, interrelated, and interoperable with the existing 
BMDS. As a result, the ASBMD System will be an information environment within an 
existing combat system comprised of interoperable computing and communication 
components. 

As stated earlier, the ability of an ASBM threat to maneuver during its terminal 
phase of flight is what differentiates it from a typical ballistic missile. Due to the distinct 
operational attributes of the ASBM threat, the unique functionality of the ASBMD 
System will be limited to the tracking and elimination of these threats during the post¬ 
boost phases of flight. The individual system functions required to complete an 
engagement sequence were defined in the requirements analysis and then documented via 
functional flow diagrams to show the interrelation of system functions and the 
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information flow between them. Figure 12 depicts the high-level, notional functional 
decomposition of the ASBMD System. The detailed decomposition of each individual 
system function is described in this section. 



Note: Creating functional decomposition diagrams ensures that all functions in the system are 
described both individually and as a part of the overall system architecture. The hierarchical 
decomposition model enables more concise decomposition of system functions. 

Figure 12. Notional ASBMD System Decomposition 
a. Search 

The basic flow of the search function is depicted in Figure 13. The search 
function initiates upon receipt of a cueing signal from either an off-board source (i.e., an 
external, BMDS network sensor) or the human operator. The cueing parameters are then 
converted to radar parameters that are used to build the sector of space that will be 
searched. After calculation of the radar parameters and required resources, the system 
evaluates the ability to perform the requested search function with organic resources. At 
this point in the functional flow, the system takes one of two actions: Either it determines 
that organic resources are available and will carry out the search function, or, in the 
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absence of organic resources, the system waits for remote search data from the BMDS to 
be passed to the tracking function. In this document, this type of track data transfer from 
the BMDS will be referred to as Launch on Remote (LoR). 



Note; The search function of the system takes operator input or data from off-board sources and 
directs organic sensors to transmit radio frequency (RF) to a specific point or area in space. 

Figure 13. Search Functional Flow Diagram 
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b. Detect 


The detect function is shown in Figure 14. The detect function begins when 
search results are received from either organic or remote sensors. The results from the 
search function are compared against the current file of existing objects, and the system 
determines if any attributes are new or have changed. If changes or new objects are 
noted, the location information is sent to the classify function. 


Detect Function 



Note; The detect function receives search results in the form of an RF return map and compares it 
with the existing RF map to determine if a new object exists. 

Figure 14. Detect Functional Flow Diagram 
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c. Classify 

The classify function is shown in Figure 15. The classify function receives object 
attributes (i.e., altitude, speed, Radar Cross Section (RCS), etc.) from the detect function 
and compares them with algorithms to determine if they represent ballistic or non- 
ballistic objects. Upon determination of the classification of the objects, the classify 
function updates the object attributes including the identification and passes the 
information to the track function. 


Classify Function 



Note: The classify function uses the object data attributes (velocity, altitude, and bearing) to 
determine the classification of an object as a ballistic object. 

Figure 15. Classify Functional Flow Diagram 


33 







































d. Track 


The track function is shown in Figure 16. The track function receives objects from 
the classify function and computes the object trajectory. After determining and updating 
the track attributes, the track file is updated and stored. The updated tracking data is sent 
to the discrimination function. 


The track function is key to the capability of the ASBMD System and is 
independent of all other system functions. The track function can be executed using 
remote or organic track data. Compilation of the object trajectory is used to determine the 
ability of the system to engage the object. 


Track Function 



Note; The track function receives the output of the classify function and determines additional 
attributes, such as trajectory, and updates the track file with the current object. 

Figure 16. Track Functional Flow Diagram 
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e. Discriminate 


The discriminate function is shown in Figure 17. The discriminate function 
receives track data from the track function and evaluates it, using predetermined 
discrimination algorithms. The output of the evaluations will be the identification of the 
number of lethal objects in the current track gate. If the output of the evaluation 
determines that there are more lethal objects than previously identified, the discriminate 
function will notify the track function of new objects to be tracked. If the output of the 
evaluation determines no new objects, the discriminate function will update the attributes 
of the existing tracks and report back to both the track and engage functions. 


Discriminate Function 



Note: The discriminate function receives and stores track data and then evaluates each received 
update against the unique discrimination algorithm. This ensures proper identification of the 
number of discrete objects that are being tracked and stored. 

Figure 17. Discriminate Functional Flow Diagram 
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f. Engage 

The engage function is shown in Figure 18. The engage function receives track 
information from the discrimination function and, upon operator initiation, will compute 
and disseminate the fire control solution for the selected target. 


After operator approval, the weapon will be deployed, and the engage function 
will compute and carry out the guidance and KA portion of the engagement. The engage 
function is also responsible for creating and communicating the current status of the 
engagement to the larger BMDS. 


Engage Function 



Note: The engage function receives operator or system commands to create and execute a fire 
control solution against an identified object. 

Figure 18. Engage Functional Flow Diagram 
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Following completion of the functional flow diagrams, the team compiled a 
system functional timeline to assess the timing requirements for completion of each 
system function and the information flow between functions throughout the complete 
engagement sequence. Figure 19 is a representation of the information flow within the 
ASBMD System and a notional timeline for this information flow within the ASBMD 
system. The timeline is based on the flight times of a nominal MRBM. This timeline was 
used to develop the criteria for the timing model employed during the AoA. 


System Functional Timeline 


Off-Board/ 
Operator I 


Search 


Detect 


Classify Track 


Discriminate Engage 


Evaluate 

Resource 

Capability 


Organic 
Not Avai^ i 


??. u 


Perform 

Search 


Search 


Results 


15 Sec 


Compare 

Output 


Locate 

Object 


Object 


Params 


6 Sec 


Updated 

Object/ 

IDAtt. 


Object 


Params 


Ballistic 

Non-BaNistic 


:v«iu«ta Obj 
Attributes 


4 Sec 


Compile 
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Update 

Track 

File 


Updated 

IDAtt. 


40-120 Sec 


Update 

Track 

Attributes 
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dentify U of 
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TT 


Evaluate 
Against 
Disc Alo 


Kill 
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Create Eng 
Solution 


Deploy 
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Control 

Weapon 


Perform Kill 
Vssessmen 


I o 

M. 


Re-Engage •--- 


60 Sec 




Total 

Nominal Missile 

Engagement Tim 

eline 










Note; Functional timeline analysis ensures that each function is allotted a specific portion of the 
timeline while maintaining the overall system timeline. Detailed functional interaction as depicted 
ensures a consistent system flow of information. This timeline was used to develop the criteria for 
the timing model employed during the AoA. 

Figure 19. ASBMD Information Flow and Functional Timeline Diagram 
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D. SYSTEMS ANALYSIS SUMMARY 


As described in the preceding sections of this chapter, the team created a number 
of system analysis artifacts for the purpose of defining and analyzing conceptual system 
architectures that could address the problem statement. Stakeholder inputs were solicited 
for the purpose of deriving high-level system requirements. These requirements were 
decomposed during FSA. The output of this functional decomposition was a detailed set 
of functional requirements and engagement timing criteria that were applied in the AoA, 
described in Chapter III. 
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III. ANALYSIS OF ALTERNATIVES 


A. OVERVIEW 

Analysis of Alternatives (AoA), as defined by Ullman, (2006), is the analytical 
comparison of multiple alternatives to be completed before committing resources to a 
designated project. DoDI 5000.02 (2008, December 8) establishes the basis for 
developing an AoA and defines the objectives of the AoA. The practice of comparing 
multiple alternative solutions has long been a part of engineering practices in the DoD. 
There is, however, a natural human tendency to propose a single alternative for 
investigation or development and justify this option rather than compare multiple options 
with the goal of choosing the best fit. Thus, government agencies, such as DoD, have 
found it necessary to encourage those proposing projects to use an AoA structure to 
properly evaluate their options. The ASBMD team has conducted an AoA using a 
modified process similar to that used in many DoD agencies. This chapter details the 
modified process that was selected. 

The objective of this AoA was to answer specific questions that were required to 
ensure that the chosen system met the requirements of the project. The outcome of the 
AoA is a single, recommended architecture that meets the functional requirements, 
schedule, and cost constraints of the system. Although the outcome is a single core 
system, the recommended architecture includes multiple elements or systems that will be 
integrated into a single architecture to combat the identified threat group. The details of 
how the system is integrated will be explained in Chapter IV. 

The purpose of the AoA for this project was to answer the following questions: 

1. What is the most cost-effective, sea-based alternative for defending CSGs 
against the emerging ASBM threat group? (This refers to the most 
cost-effective approach that meets the key functional requirements identified 
during the CONOPS and functional analysis portion of the project.) 
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2. Which alternative introduces the least amount of risk in all eost, sehedule, and 
performance aspects? 

3. Which alternative allows for the shortest fielding and deployment schedule? 
(This addresses the emergent need aspect of the problem.) 

B. PROCESS 

The ASBMD team created a modified analysis teehnique, as depicted in 
Figure 20. As the figure shows, the process is iterative, and there is a natural increase in 
detailed analysis artifacts and their fidelity, as the process flows up the pyramid. The key 
to the process is the development of a well defined set of baseline documents at the start 
of the analysis. Baseline documents in this case are the documents that the team ereated 
during the system functional analysis portion of the product; they consist of the 
CONOPS, ICD, DRMs, and functional flow diagrams. Although the key is to maintain 
stable baseline doeuments, the proeess is designed to have feedback loops that drive 
updates to the preeeding steps as additional details are defined. For example, as the team 
identified the key funetional attributes (KFAs), the analysis demonstrated the need to add 
another level of detail to the requirements that were developed during the CONOPS and 
ICD phases of the project. These modifications are not functional changes to the 
requirements, but they ensure that the attributes being developed and analyzed are correct 
and consistent with the scope of the project. Updating requirements as the technical 
assessment progresses ensures that traceability is maintained throughout the project. Each 
step in the process will be detailed in the following sections of this chapter. The outeome 
of the AoA is a detailed set of analysis artifacts that were applied in the concept 
architeeture and integration portions of the projeet. 
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Note; The AoA process designed by the ASBMD team ensured that a complete and consistent 
concept architecture was created that was reinforced by detailed analysis artifacts. The ASBMD 
team used the AoA process to ensure that traceability was thorough and complete through all of 
the analyses and artifacts. 

Figure 20. ASBMD Analysis of Alternatives Process 
1. Requirements Refinement 

The success of this process depends on the early definition and refinement of the 
requirements and functions of the system. Since the requirements and their associated 
documents (CONOPS, ICD, etc.) are the basis for the analysis and the ultimate selection 
of an alternative, it is imperative that they are made clear and concise as early as possible 
in the analysis process. Requirements changes are inevitable; therefore, a clear line of 
feedback (as depicted in Figure 20) to all parent documents is key to ensuring that the 
engineering of the system is consistent and correct. The AoA process began with a set of 
high-level requirements that were derived from the CONOPS and ICD. Each requirement 
is associated to the key functions that were identified in Chapter II. Verification that the 
derived requirements remained aligned with the key functions continued throughout the 
AoA. As each step of the process was started and subsequently completed, the engineer 
assigned to a specific function assessed the requirements and associated documentation to 
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ensure that they were still correct, complete, and concise. Although the process is 
continuous, the number of modifications and clarifications to the requirements reduces 
considerably as the assessment advances up the levels of the pyramid. This is attributable 
to each step building on the analysis performed and the artifacts produced for the 
preceding steps. The majority of the requirements changes occurred during the creation 
of KFAs; this is due to the analysis having determined the need for additional 
requirements details to support the functional requirements of the system. A depiction of 
this update process is shown in Figure 21. This represents the iterative refinement aspect 
of the requirements development process originally depicted in Figure 7. 


CONORS 


• Update Concept to Post-Boost Phase 




1 System 


Requirements! 



T 1 




' ' r 

Functional 

- 

1 

Analysis 

1 

1 

1 

1 

1 


1 

1 


• Update to reflect KFA Details 


Normal Flow 

- — Updates Required 
- Item Updated 


• Update Concept to Post-Boost 
Phase 


Models and 
Simulation 


Concept 

Architecture 


Note: Updates were applied to system requirements and associated documentation as needed 
throughout the analysis process to ensure correctness and completeness. 

Figure 21. Process Flow for Requirements Refinement and Documentation Updates 
2. Key Functional Attributes 

The next step in the process was the creation of KFAs. KFAs are the system 
attributes that are required to effectively evaluate system performance against the 
requirements that were identified during the ICD phase that were further detailed during 
the requirements refinement step. These are the system attributes that must be analyzed to 
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determine the functional capabilities of candidate systems that are chosen for assessment 
during the AoA. The KFAs that the team identified were those attributes that, when 
analyzed, would provide a clear and objective view of the capabilities of the candidate 
systems. For example, for the search function, the team identified the scan rate, search 
volume, and angular resolution as the functional attributes that would be used to evaluate 
each candidate system. 

The ASBMD team identified KFAs for each functional area depicted in Table 7. 
As previously described, the feedback loop from each step in the process to the preceding 
steps ensures a consistent flow and commonality across all functions and requirements. 
During the analysis and creation of the KFAs, the team identified multiple KFAs that 
demonstrated a need for the requirements to be refined. The requirements refinement 
ensured sufficient detail to support the KFAs that were identified. 

Table 7. Key Functional Attributes 

Note; The ASBMD team created KFAs to identify the attributes that, when analyzed, would 
provide detailed analysis artifacts to assist in the decision of the final elements or systems that 
would comprise the concept architecture. KFA development was an important factor in the further 
refinement of system requirements and timing analysis. KFAs were weighted by stakeholder 
inputs and became criteria for system evaluation during the AoA. 


Analysis Area 

Recommended Attribute Analysis 

Search 

Search Rate (Scan Rate) 

Search Volume Capabilities 

Range 

Angular Resolution 

Detection 

Signal-to-Noise Ratio 

False Alarm Rate 

Probability of Detection (Adjusting Target and Environmental Attributes) 

Radar Range Calculation for Maximum Detection Range 

Tracking 

PRF and Tracking Errors 

Effective Aperture and Resolution Calculations 

Effects of Tracking Ranges Given Tracking and Turning Gate Changes 

Transition-to-Track Timeline Analysis 

Intercept Variants 

General Systems Capability Analysis 

Kill Timeline Analysis by Varying Range 

Maximum Effective Ranges 
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3. System Attribute Analysis 

The system attribute analysis step of the AoA process is the point where the team 
began the identification of the analysis artifacts that would be used to evaluate each KFA 
identified in the earlier steps of the AoA process. Analysis artifacts identified by the team 
included tables, graphs, and charts that would provide clear, easily understood 
documentation to assist in the final architecture decision. After creation of the KFAs, the 
team defined a list of candidate artifacts that were used to perform an analytical 
comparison of the candidate systems that would be defined in the successive steps of the 
process. For example, as depicted in Figure 22, to evaluate the search function of the 
candidate systems, the team created artifacts to evaluate maximum detection range vs. 
RCS and minimal detectable signal vs. range. These analysis artifacts were used to assist 
in the one-to-one comparison of each concept architecture in the system comparison 
phase. Additional system attribute analysis sheets were created for each system function; 
a compilation of these analysis sheets is provided in Appendix E. 
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Pf vs Range 



750 1750 2750 3750 4750 5750 


SPY-1 
SPY-3 
Cobra Judy 
GBR-P 


Range to Target, KM 


Min Det Signal vs Range 



Range to Target, KM 


-♦-SPY-1 
SPY-3 
Cobra Judy 
GBR-P 


Note: System attribute analysis provides the detailed analysis technique that the team used to 
evaluate each candidate element or system. The analysis artifacts were used to assist in the one-to- 
one comparison of each concept architecture. 

Figure 22. System Attribute Analysis Sheets Example 
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4. System Comparison 

Following creation of the KFAs and system analysis sheets, the team defined a list 
of candidate elements and/or systems for each defined function. This list was derived 
from the documents created during the initial system research and analysis phases of the 
project, in conjunction with the operational experience of each team member. Although 
the list may appear somewhat limited, the team tried to bound the size of the list to 
contain only those options that were feasible and met the functional, cost, and schedule 
requirements of the project. Each team member then performed a detailed analysis of 
each candidate system to gather the required information to evaluate the KFAs. To ensure 
that the project was kept unclassified, the detailed analysis and information gathering 
included only information that was readily available via public domain sources. After 
data were gathered, each team member created specific system analysis sheets for each 
candidate system. Creation and evaluation of the system analysis sheets allowed the team 
to rank each system according to how well it performed its function. The team was also 
able to identify pros and cons for each system to assist in the ranking. After a detailed 
analysis was performed, the data were combined into a single system comparison 
spreadsheet, as shown in Table 8. The outcome of this step is a consolidated list of 
elements and/or systems that were evaluated on their ability to meet the performance 
requirements, as well as a one-to-one comparison based solely on how each system 
performed against the KFAs. A full system-of-systems comparison occurred later in the 
process and considered other aspects of the project, such as risk assessment and 
cost/schedule requirements. 
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Table 8. System Comparison 


Note: The team used system comparison sheets to perform comparisons of each system identified 
to meet the associated requirements. The sheets displayed the functional and operational pros and 
cons for each system, which the team found useful in determining the final architecture. 


Function Name (Search/Detection) 

Options 

Performance Parameters 

Requirements 

Pros / Cons 

Max 

Range/ 

Accuracy 

Max 

Power 

Ae 

(Effective 

Aperture 

Size) 

Smin 

SPY-1 B(D) 

* 1460 KM 

3 MW 

20 m''2 

-13 dB 

ASBMD System shall be capable 
of searching a designated search 
sector of not less than 30 degrees 
at a distance of not less than 

750 km in less than 2 seconds, 
when cued by either off board 
intelligence or the onboard 
operator. 

Pro: Mature, proven system capability 

Con: Shorter maximum range limits the 
maneuverability options of the Fleet 
Con: Heavily reliant on intelligence data to 
allow for resource focusing 

SPY-3 

** 2527 KM 

4.5 MW 

23 m''2 

-23 dB 

ASBMD System shall be capable 
of searching a designated search 
sector of not less than 30 degrees 
at a distance of not less than 

750 km in less than 2 seconds, 
when cued by either off board 
intelligence or the onboard 
operator. 

Pro: Greater search range and accuracy 
capabilities than the SPY-1 

Pro: Greater peak power and Ae size 
allows for search and detection of 
smaller RCS 

Con: Unproven system that is still under 
development 

Con: Power usage to excite radar elements 
exceeds that of current ship 
capabilities 

Con: Unable to uplink with current weapon 
inventory 

Cobra Judy 

** 2681 KM 

7 MW 

26.4 m''2 

-20 dB 

ASBMD System shall be capable 
of searching a designated search 
sector of not less than 30 degrees 
at a distance of not less than 

750 km in less than 2 seconds, 
when cued by either off board 
intelligence or the onboard 
operator. 

Pro: Greatly increases search and 
detection ranges 

Pro: Allows greater operational 
maneuverability 

Con: Large power consumption 
requirements 

Con: Unable to control current weapons 
Con: Too large to fit onto current 
operational naval vessels 

GBR-P 

** 3297 KM 

8 MW 

20.4 m''2 

-23 dB 

ASBMD System shall be capable 
of searching a designated search 
sector of not less than 30 degrees 
at a distance of not less than 

750 km in less than 2 seconds, 
when cued by either off board 
intelligence or the onboard 
operator. 

Pro: Increased search and detection 
ranges 

Pro: Increases operational capability of 
fleet 

Con: Power consumption is too great 

Con: Weight and size are restrictive 

Con: RCS signature much too large for 
naval vessel 

Con: No weapon control capability 

All calculations assume 30 degree search sector. 

* Derived from Aegis BMD briefing. 

** See specific Radar Calculation Sheets. 
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5. Model Creation 


After candidate systems were identified and a detailed analysis was performed for 
each system, the team created high-level system models using the Arena modeling tool 
set. Although this was not the only modeling tool used during the analysis process, the 
team chose Arena as the primary modeling tool due to the team's familiarity with the 
program and the its capabilities. Arena is a useful tool when modeling both high-level 
systems and subsystems from a timing perspective. It allows easy manipulation of the key 
timing drivers identified by the user. This was important to the team because system 
timing was recognized early in the analysis process as a critical dependency in this 
assessment. The graphical interface provides ease in the creation of metrics and charts 
that measure and monitor KSAs. Early in the project, the team conducted and 
documented a modeling proficiency demonstration using Arena. The purpose of this 
exercise was to illustrate the team's ability to use Arena to generate a high-level system 
simulation of BMD functions over the course of a ballistic missile threat flight from 
detection to intercept. 

The modeling output examples described below are examples of the functional 
modeling analysis conducted by the team. Functional modeling was the process of 
creating a model that contained each system function that was identified during the 
functional decomposition phase. As the project progressed and the team identified 
specific candidate systems/elements that could perform the identified functions, the 
system-specific timing values and behaviors of candidate systems were inserted into the 
model. Because each candidate system was required to fulfill the identified system 
functions, the team did not create a separate model for each candidate system. However, 
the team used the model to prove or disapprove any assumptions that the team had for 
each candidate system. 
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Two separate levels of Arena models were created for this step of the process. 
These models are shown in detail in Appendix E. The gross system model depicted in 
Figure 23 was used primarily to evaluate system timing and to identify major 
impediments to system integration. 



Note; The gross system model is used to identify the ability of the concept architecture to meet the 
overall system timing constraints. This model assisted in understanding the ability to integrate 
each element or system into a system of systems. 

Figure 23. Gross System Model 

After timeline analysis was performed using the gross model shown in Figure 23, 
the team created multiple sub-models to assist in the evaluation of the candidate systems. 
Each candidate system was evaluated individually, using the model depicted in Figure 24. 
This allowed the team to understand the dependencies created as each system was 
integrated. The models were used to ensure that the systems, when integrated, met the 
overall performance requirements for the system of systems under varying conditions. 

The team modified attributes, such as RCS, range, probability of kill (PK), probability of 
detection (Pd), and flight times, to ensure that the systems still met the overall system 
requirements. Subsequent sections of this document will describe the steps taken to 
narrow the candidate systems using interoperability as one of the main requirements. 
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Note: The detailed system model is used to identify and understand the dependencies created as 
each system was integrated to create a system of systems solution. 

Figure 24. Detailed System Model 

When the candidate architectures were narrowed to two, the model depicted in 
Figure 25 was employed to help ensure that the selected solution met the overall system 
requirements when integrated at the system-of-systems level. The outcome of the model 
analysis provided additional details that were used to assist in the final architecture 
decision. The results of the model analysis were used to generate the system-of-systems 
analysis and are described in section C below. 
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Note: Sub-models were used to ensure that the chosen elements or systems met the timing 
requirements of the overall system. The sub-models also assisted in identifying the key 
interactions required to integrate into a systems-of-systems architecture. 

Figure 25. Functional Sub-Model Breakout Example 
C. SYSTEM-OF-SYSTEMS ANALYSIS 

As previously discussed, the AoA process covered only the analysis of the 
individual candidate elements and/or systems; the system-of-systems analysis portion of 
the project is where the team performed the detailed comparison of each of the candidate 
architectures integrated at the system-of-systems level. This process examined each 
system’s ability to meet not only the performance requirements, but also its ability to 
meet the identified cost and schedule constraints. The outcome of this analysis was 
multiple system configurations that could meet the identified functional requirements. 
The configurations were ranked according to the capability to be deployed quickly and 
cost effectively and were compiled into a ranked list. This list illustrates that one solution 
can be deployed quickly, while continued development of an alternate solution can 
introduce greater capability at a later time. 

1. Concept Architecture Analysis 

The next step was the formulation of end-to-end, system-of-systems concept 
architectures that could be used to combat the ASBM threat. The team used the analysis 
artifacts that were created during the AoA process described above to identify the best fit 
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solutions for each function. After determining the system or element that was the best fit 
for each function, the team used a mixture of engineering analysis, experience, and 
discussion to derive multiple combinations of elements that could be integrated into a 
coherent system of systems. The team used the models described in section B of this 
chapter to ensure that, when integrated, each candidate architecture could meet the 
overall timing defined in the system requirements. 

The team then created the concept architecture analysis comparison sheet, 
depicted in Figure 26, to document the elements/systems that were integrated into 
candidate architectures. 
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External Sensors 

C2BMC 

Link 16 
CEC-D 

Modified Zumwalt 
Fire Control 
AN/SPY-3 

N/A 

Rail Gun 

Mod 1 

Ballistic Round 

1b 

External Sensors 

C2BMC 

Link 16 
CEC-D 

Modified Zumwalt 
Fire Control 
AN/SPY-1 

S-Band Link 

MK-57 

SM-3 

Dual Band 

1c 

External Sensors 

C2BMC 

Link 16 
CEC-D 

Modified Zumwalt 
Fire Control 
AN/SPY-3 

N/A 

Laser 

System 

N/A 

2 

External Sensors 

C2BMC 

Link 16 
CEC-D 

Modified Aegis 
Fire Control 
AN/SPY-1 

S-Band Link 

MK-41 

SM-3 

Dual Band 

2a 

External Sensors 

C2BMC 

Link 16 
CEC-D 

Modified Aegis 
Fire Control 
AN/SPY-3 

X-Band Link 

MK-41 

SM-3 

Dual Band 

3 

External Sensors 

C2BMC 

Link 16 
CEC-D 

Modified Zumwalt 
Fire Control 
Modernized 
GBR-P 

X-Band Link 

MK-57 

SM-3 

Dual Band 

3a 

External Sensors 

C2BMC 

Link 16 
CEC-D 

Modified Aegis 
Fire Control 
Modernized 
GBR-P 

X-Band Link 

MK-41 

SM-3 

Dual Band 

Notes: 

1. System configurations were not evaluated if they were ruled out in earlier processes or were immediately deemed not interoperable 
(system comparison, cost analysis, stakeholder discussions, etc.). 

2. Fire control and weapons would be shipboard only due to range from land sensors. 

3. No tail chase scenarios were identified; therefore, this requirement was not driven to the system architectures. 

4. External sensors are defined as BMDS networked sensors, to include AN/TPY-2, additional AN/SPY-1 assets, airborne sensors, and 
Overhead Persistent Infrared (OPIR) assets. 

5. Launch on Remote (LoR) will be the base scenario when external sensors are available. 

6. Specified Fire Control Systems are hull-specific and are not interchangeable (i.e., Aegis = DDG 51 class hull, etc.). 


Note: Architecture comparison sheets document each of the elements or systems that could be 
combined to meet the overall requirements of the ASBMD system. 

Figure 26. Concept Architecture Analysis Comparison Sheet 
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The six elements/systems are defined as follows: 


Network Sensors: 

• This term refers to the sensors that are already included in the BMDS 
network (AN/TPY-2, AN/SPY-1, Upgraded Early Warning Radar 
(UEWR), and Overhead Persistent Infrared (OPIR)). 

Interoperability: 

• Command and Control Battle Management and Communications 
(C2BMC) is the core interoperability and element coordination 
architecture for the BMDS. 

• Eink 16 is the high speed, E-Band digital data link currently in service 
throughout U.S. Navy systems and networks. 

• The Cooperative Engagement Capability-Distributed (CEC-D) system is 
an updated Cooperative Engagement Capability (CEC) system that adds 
the capability to process space tracks, including updated algorithms to 
allow processing of tracks with very large velocities. The CEC-D system 
has an initial operational capability (IOC) of early 2010. 

Shipboard Fire Control Systems: 

• AN/SPY-1 is the is the primary air and surface radar for the Aegis Combat 
System installed in the USS Ticonderoga (CG 47) and USS Arleigh Burke 
(Guided Missile Destroyer (DDG) 51)-class warships. It is a 
multifunction, phased-array radar capable of search, automatic detection, 
transition to track, tracking of air and surface targets, and missile 
engagement support. 

• AN/SPY-3 is an active, phased-array X-band radar designed to meet all 
horizon search and fire control requirements for the next generation of 
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U.S. Navy ships. It supports new ship design requirements for reduced 
RCS, significantly reduced manning requirements, and total ownership 
cost reduction. The multifunction radar is designed to assume the 
functions of five separate radar systems that are currently in service. 

SPY-3 is scheduled to IOC in 2012. 

• Ground-Based Radar-Prototype (GBR-P) is an X-band phased array radar 
and fire control sensor that provides precision discrimination and 
interceptor fire control support capability to the BMDS. There is currently 
only one GBR-P installation, located at Kwajalein Atoll. While the full 
ground-based concept would not be suitable for this assessment, what was 
considered is a modernized, shipboard-scale X-band phased array radar 
that is capable of providing the same in-flight interceptor communications 
system (IFICS) and in-flight target update (IFTU) support featured in the 
GBR-P system. 

Data Link; 

• S-Band Data Link is used by the AN/SPY-1 radar for acquisition and 
midcourse communication with Standard and Evolved Sea Sparrow 
Missile variants. The S-Band Data Link is primarily used by legacy Aegis 
systems. 

• X-Band Data Link is used by the AN/SPY-3 radar for acquisition and 
midcourse communication with Standard and Evolved Sea Sparrow 
Missile variants. The X-Band Data Link is the preferred ownship missile 
communication mechanism for systems being designed for use in a littoral 
environment due to its improved clutter rejection and anti-jamming 
capability. 
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Launcher Mechanism: 


• MK-41 Vertical Launching System (VLS) is the currently fielded, 
canister-based, fixed shipboard launcher. It is capable of firing a variety of 
ordnance items and, if appropriately configured, is able to simultaneously 
support multiple missions, including both Anti Air Warfare (AAW) and 
BMD. 

• MK-57 VLS is an open-architecture-compliant launcher developed for the 
DDG 1000 platform. It is designed to accommodate existing VLS 
encanistered missiles but provides for the growth in volume and weight 
expected for future missile systems. It is scheduled to IOC in 2012. 

• Rail Gun is a weapon system that moves a projectile along a pair of metal 
rails using two sliding or rolling contacts. The contacts permit a large 
electric current to pass through the projectile, which interacts with the 
magnetic field around each rail to accelerate the projectile. Although the 
U.S. Navy has tested a rail gun that is capable of accelerating a 3.2 
kilogram (kg) projectile to greater than Mach 7, no Navy platform can 
currently support the space and infrastructure needs (i.e., provide power 
and cooling) that would allow further development and deployment of this 
functionality. 

• Laser weapons system is a megawatt-class chemical oxygen iodine laser 
(COIL) that could be modified for integration in U.S. Navy ships. In BMD 
applications, this type of laser is primarily designed to destroy ballistic 
threats in their boost phase. A shipboard laser weapon system is not 
feasible for BMD scenarios due to proximity to the launch site that would 
be required for a boost phase intercept; however, MDA has developed and 
tested the Airborne Laser (ABL) platform for boost phase intercept 
capability. 
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Interceptor: 


• SM-3 is the U.S. Navy’s midcourse ballistic missile interceptor. The 
certified SM-3 Block lA is currently in service. SM-3 Block IB, which 
features enhanced capabilities and would be the desired candidate for 
consideration in the ASBMD scenario, is scheduled for IOC in 2011. The 
Block IB design includes an advanced, two-color, infrared seeker for 
enhanced discrimination capabilities. Its Throttleable Divert and Attitude 
Control System (TDACS) will provide the kill vehicle with greater agility, 
which is advantageous for use against maneuvering threats. 

• Rail Gun Mod 1 Ballistic Round is a lightweight projectile designed for 
use with the developmental rail gun concept. 

Although many systems could have been analyzed, the team included only those 
that met the functional capabilities and performance parameters identified during the 
functional analysis and system comparison phase. This resulted in the creation of 
candidate architectures that were more feasible and could potentially meet the 
performance criteria and system requirements, including cost and schedule constraints. 

2. Selection of Concept Architecture Options for Evaluation 

During this portion of the process, the team performed detailed analyses of each 
candidate architecture that was identified during the earlier steps of the assessment. The 
detailed analysis included identification of the pros and cons for each architecture. The 
pros and cons included both technical and programmatic issues and were identified using 
available literature and working-level knowledge of the team members. After detailing 
and analyzing each candidate architecture, the team narrowed the concept architectures 
based on all artifacts that had been created up to that point in the process. Those artifacts 
included the KFAs, models, systems attribute sheets, and system requirements. Based on 
system availability, ability of the systems to meet stakeholder requirements, and 
performance of the systems in the models, the team ranked the concept architectures and 
provided detailed rationale to justify why each concept architecture option was or was not 
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chosen. The ranking of the top concept architecture options and the associated rationale 
for each are depicted in Table 9. Next, the team created the architecture diagrams for the 
top three ranked choices to provide a graphical representation of each option. The 
diagrams are shown in Figures 27, 28, and 29; these contain the pros and cons for each 
system. 
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Table 9. Ranking of Concept Architecture Options 

Note: Ranking of the systems assists in focusing the detailed analysis and artifact creation to only 
those options that meet the high-level requirements, cost, and schedule constraints. The options 
labeled “not ranked” (NR) were eliminated due to their inability to meet one or more of these 
constraints. 


Option 

# 

Architecture Descriptor 

Evaluation 

Priority/Rank 

Rationale 

1 

Zumwalt Fire Control with 
Updated Discrimination and 
Tracking Algorithms 

3 

• Zumwalt IOC is-2014. 

• Option requires changes to SPY-3 
and Combat Systems. (Near field 
range testing required.) 

1a 

Zumwalt Fire Control with 
Updated Discrimination and 
Tracking Algorithms, Weapons 
Control Changes for Rail Gun 

NR 

• Zumwalt IOC is-2014. 

• Very high development, integration, 
and testing costs 

• Schedule constraints 

1b 

Zumwalt Fire Control 
integrated with SPY-1 Radar 
guidance and control 

4 

• Zumwalt IOC is-2014. 

• Very high development, integration, 
and testing costs with integrating 
new radar into existing Fire Control 

• Schedule constraints 

1c 

Zumwalt Fire Control with 
Updated Discrimination and 
Tracking Algorithms, Weapons 
Control Changes for Laser 
System 

NR 

• Zumwalt IOC is-2014. 

• Laser System IOC is beyond 2015. 

• Very high development, integration, 
and testing cost 

• Very high risk of 
technology/capability not being 
sufficient 

2 

Modified Aegis Fire Control 
with updated Discrimination 
and Tracking Algorithm 

1 

• Quick development and deployment 
with minimal integration and testing 
cost 

• Minimal schedule impact. 

• Availability could meet need dates. 

2a 

Modified Aegis Fire Control 
integrated with SPY-3 Radar 
for guidance and control 

2 

• Platform cannot support the power 
and cooling requirements of SPY-3. 

• Integration and testing timeline does 
not support need dates. 

3 

Modified Zumwalt Fire Control 
integrated with Modernized 
GBR-P System for guidance 
and control 

NR 

• Option involves a very long and 
costly development, integration, and 
testing timeline that would not meet 
need dates. 

• Complex integration effort required 
to use GBR-P for ordnance control. 

3a 

Modified Aegis Fire Control 
integrated with Modernized 
GBR-P System for guidance 
and control 

NR 

• Option involves a very long and 
costly development, integration, and 
testing timeline that would not meet 
need dates. 

• Platform cannot meet the cooling 
and power requirements of the 

GBR-P System. 
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Option 1 Concept Architecture 
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Positives 

o Increased detection and tracking 
ranges 


Negatives 

o Cannot meet cost and schedule 
o IOC of DBR Radar does not support 
urgent requirement 

o Cost and schedule required to retest 
fire control chain is excessive 
o Missile uplink has not been proven 


Note: The Option 1 concept architecture depicts the integrated solution using the Zumwalt Combat 
System as the baseline configuration. This figure identifies the pros and cons for this architecture. 

Figure 27. Option 1 Concept Architecture 
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Note: The Option 2 concept architecture depicts the integrated solution using the Aegis Combat 
System as the baseline configuration. This figure identifies the pros and cons for this architecture. 

Figure 28. Option 2 Concept Architecture 
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Option 2a Concept Architecture 




Aegis Fire Control 

C2PJ [ WCS I X 
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SPY-3 Radar 
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Positives 

o Updated Aegis Fire Control with new 
Tracking and Discrimination 
Algorithms 

o Assumes Engage on Remote using 
data from external sensors 

o Allows for “backup" ability to engage 
after re-entry using organic SPY-3 
resources 

o Increased detection and tracking 
ranges 


Negatives 

o Cannot meet cost and schedule 
o IOC of SPY-3 Radar does not support 
urgent requirement 

o Cost and schedule required to retest 
fire control chain is excessive 


Note: The Option 2a concept architecture depicts the integrated solution using a hybrid Zumwalt 
and Aegis Combat System as the baseline configuration. This figure identifies the pros and cons 
for this architecture. 

Figure 29. Option 2a Concept Architecture 
3. One-to-One Comparison of Ranked Concepts 

The final step of the AoA portion of the project was to compare the ranked 
concept architectures to ensure a complete understanding of the magnitude of the impacts 
associated with employment of the concept architectures. For example, some of the 
architectures would result in software-only changes, while others would result in 
hardware and software changes that could impact the ability to meet the schedule 
constraints of the project. The comparison analysis resulted in development of a 
capabilities and limitations sheet, shown in Table 10. Each concept option would provide 
the required capability to combat the threat identified in the problem statement, but the 
limitations of implementing some concept architectures could result in integration 
challenges that would render the entire BMDS system less agile or capable. The next 
activity that the team undertook during this step was conduct of a performance and 
capability comparison assessment summary for the ranked concept architectures. This is a 
side-by-side comparison of the top three architectures identified in the earlier steps. 

Table 10 shows the top three ranked options that the team chose and a one-to-one 
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functional comparison of these options. The key attributes used to evaluate the options 
are also shown in Table 11; key attributes included engagement mode, engagement 
performance, and maneuverability. The architectures were also evaluated against cost and 
schedule requirements to ensure that the chosen architecture met all of the requirements 
created during the ICD and CONOPS portion of the project. 


Table 10. Concept Architecture Capabilities and Limitations 

Note: The comparison analysis performed resulted in a capabilities and limitations definition for 
each candidate architecture. The required capability to combat the threat was identified in the 
problem statement, but the limitations of implementing some concept architectures could result in 
integration challenges that may render the entire BMDS system less agile or capable. 



Option 1 

Option 2 

Option 2a 

Operational 

Flexibility 

• Allows LoR and EoR 
due to compatibility 
with C2BMC and 
addition of CEC-D. 

• Not backwards 
compatible with SM-T. 

• Allows EoR and LoR 
due to compatibility 
with C2BMC via Link 

16 capability. 

• Allows LoR and EoR 
due to compatibility 
with C2BMC and the 
addition of CEC-D. 

• Not backwards 
compatible with SM-T. 

Implementation 

and 

Operational 

Deployment 

• Zumwalt system 
manages onboard 
assets and sensors 
and manages missiles 
In flight via 

X-band link. 

• Midcourse guidance 
updates based on 
remote data from 
external BMDS 

sensors. 

• Aegis system 
manages onboard 
sensors and missiles 
via S-Band link. 

• Midcourse guidance 
updates based on 
remote data from 
external BMDS 
sensors. 

• Aegis system 
manages onboard 
sensors and missiles 
via S-Band link. 

• Midcourse guidance 
updates based on 
remote data from 
external BMDS 

sensors. 

Fire Control 
Loop Integrity 

• Achieved via 
local/organic SPY-3 
radar and/or 
external/remote 
sensors via the BMDS 
network. 

• Achieved via 
local/organic 
(AN/SPY-1) radar 
and/or external/remote 
sensors on the BMDS 
network. 

• Achieved via 
local/organic SPY-3 
radar and/or 
external/remote 
sensors via the BMDS 
network.. 

Raid Capability 

• AN/SPY-1 can provide 
additional radar 
resources for search, 
tracking, and 
discrimination. 
(Requires new C2BMC 
radar control 
functionality.) 

• SPY-3 can provide 
additional radar 
resources for search, 
tracking, and 
discrimination. 
(Requires new C2BMC 
radar control 
functionality.) 

• AN/SPY-1 can provide 
additional radar 
resources for search, 
tracking, and 
discrimination. 

(Requires new C2BMC 
radar control 
functionality.) 
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Table 11. Side-by-Side Functional Comparison 


Note: The side-by-side functional comparison assists in identifying the most capable candidate 
architecture when compared against common functional performance criteria. 




Option 1 

Option 2 

Option 2a 



Zumwalt/SPY-3 

Aegis Baseiine 

Aegis/SPY-3 

Primary Engagement Mode 

Engage-on-Remote 

(EoR) 

EoR 

EoR 

One-on-One Engagement 
Performance 

Similar 

Battle Space 
Performance 
One-on-One 

Launch 

Window 

Better: Uses SPY-3 
with fully populated 
array 


Better: Uses SPY-3 
with fully populated 
array 

Raid 

Small Raid 

Similar 

Capacity 

Large Raid 


Better: Radar 
resources greater for 
in-flight missiles 


Missile Data Link Margin/ 
Information Assurance (lA) 

Better: Uses P3I link 
with X-band 


Better: Uses P3I link 
with X-band 

Cost 

Higher: Requires 
additional hardware 
and advanced program 
testing 

Best: Leverages 
existing resources 

Higher: Requires 
additional hardware 
and advanced 
program testing 

Schedule and 

Programmatic Risks 

Higher: More 
challenging 
development, 
integration and testing 
effort 

Lower: Shorter build 
test and certify 
timeline = lower cost 

Higher: More 
challenging 
development, 
integration and testing 
effort 


Table 12 demonstrates the impact of modifications that each system introduces to 
the architecture. Significant changes require additional time and funding to implement. 
Therefore, options requiring extensive changes were deemed unable to meet the schedule 
constraints of the project. 
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Table 12. Comparison of Candidate Architectures by Impact of Modification 

Note: The impact of changes that each system introduces to the architecture is a key consideration 
in making the final decision. Significant changes require more time and funding to implement. 
Therefore, most concept architectures requiring extensive changes were deemed unable to meet 
the schedule constraints of the project. 


Area of Modification 

impact of Modification 

Option 1 

Zumwait/SPY-3 

Option 2 
Aegis/SPY-1 

Option 2a 
Aegis/SPY-3 

Externai Sensors 

None 

None 

None 

Missiie 

Moderate 

None 

Moderate 

Core Combat Systems 

Negligible 

Negligible 

Negligible 

Launcher 

None 

None 

None 

Radar 

Significant 

None 

Significant 


D. COST ANALYSIS 

When evaluating eost, eomparing eandidate alternatives is important to determine 
their relative eosts with respeet to a baseline set of requirements or eapabilities. The three 
eandidate options were evaluated to determine the total eost of implementation. To 
ensure that a fair eomparison was performed, the team separated the eosts for eaeh option 
into two separate eategories. The first category that the team evaluated was the cost for 
software-related changes, including requirements, design, code, and testing needed to 
upgrade or develop the required capabilities. The estimated software-related costs for 
each of the candidate architectures are shown in Figure 30. 
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Note: Software cost of the selected architecture helps to identify the resources required to field the 
system. The cost analysis was a significant variable in the concept architecture decision-making 
process. 

Figure 30. Software Cost 

The second category of cost analysis was associated with hardware-related 
changes. Some options required few hardware changes, as most of their required updates 
were only changes to software algorithms. Figure 31 shows the comparison of the 
estimated hardware-related changes for the candidate architectures. 
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Note: The hardware cost for the selected architecture is key to ensuring that the selected 
architecture can meet the schedule requirements of the system. High hardware cost is always 
accompanied by testing and certification costs, which are significant schedule drivers. 

Figure 31. Hardware Cost 

Following these individual software and hardware cost comparisons, the team 
conducted a total cost comparison that evaluated software, hardware, and system 
integration costs for each option. The comparison of the total cost to implement each 
option is shown in Figure 32. As depicted in this figure. Option 2 was determined to have 
the lowest total development cost. 
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Note: Total development cost is the total cost required to field the concept architecture. For the 
purpose of this study, the total cost is the sum of the hardware and software costs. 

Figure 32. Total Development Cost 
E. RISK MANAGEMENT SUMMARY 

Risk management is a concept used to assess and handle events that might 
adversely impact a system development effort. Mitigating these impacts increases the 
likelihood of a successful system development effort. The ASBMD team utilized the risk 
management process described in the Risk Management Guide for DoD Acquisition 
(DoD, 2006, August). Team members identified the risk root causes in the areas of 
project management and systems engineering, and each root cause was analyzed for the 
likelihood of the event occurrence and the consequence to the effort upon occurrence. 

The team developed and reviewed risk mitigation plans in an iterative manner throughout 
the project and used them to monitor progress toward closure of each risk. Risk 
assessment was a significant aspect of the AoA process, as each system and end-to-end 
architecture option was considered in context of its potential to introduce risk to the 
system or mitigate system risk. Several architecture options were eliminated from further 
evaluation in the AoA because they introduced cost and schedule risk to the ASBMD 
system, either due to lack of maturity or to an assessed inability to integrate effectively 
with the BMDS. The team used this information to aid in the selection of the option that 
best met system requirements while posing the least perceived risk to system integration. 
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fielding, and performance. More information about the risk management process and its 
use by the ASBMD team is available in Appendix F. 

F. FINAL SELECTED SOLUTION 
I. Core Solution Architecture 

As previously described, each candidate architecture option was ranked and 
evaluated based on its ability to meet the identified functional and programmatic 
requirements of the ASBMD System. The selection of the core solution architecture from 
the final three evaluated options was based on the primary objective of eliminating the 
ASBM threat during the midcourse phase of ballistic flight. This approach requires the 
system solution to communicate efficiently and effectively within the BMDS network 
and on the capability of receiving and processing data from all network sources. 
Stakeholder concerns related to interoperability and performance were balanced by the 
team with the cost and schedule constraints associated with the needs statement. These 
factors were applied during the AoA to determine the best system of systems solution for 
the ASBMD system. The side-by-side functional and programmatic comparisons, cost 
analyses, and risk assessment of the final three options clearly show that Option 2 was the 
best fit for the ASBMD System requirements. Figure 33 shows this option’s 
configuration in detail and depicts the overall architecture of the core solution. 
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Note: The selected core architecture consists of the Aegis Combat System and the SM-3. This 
architecture relies heavily on a software baseline upgrade to introduce the ability to eliminate the 
ASBM threat. 


Figure 33. Selected Core Architecture 


G. AOA SUMMARY 

As described in this chapter, the purpose of the ASBMD AoA was to determine 
the single recommended architecture that meets the functional requirements, schedule, 
and cost constraints associated with a solution to the problem statement. The 
recommended solution—Option 2—includes multiple systems that, when integrated, will 
function as a single combat system to defeat the ASBM threat. The discussion of how the 
system is integrated follows in Chapter IV. 
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IV. INTEGRATED SYSTEM SOLUTION 


A. PURPOSE 

As described in Chapter III, the team implemented the modified AoA process and 
conducted a detailed analysis to identify the candidate architecture that could be used to 
fill the stated capability gap. The team provided detailed pros and cons for each system 
and element of each candidate architecture to help select the final configuration that best 
met the functional and programmatic requirements. The team described methods used to 
narrow the candidate architectures into a single set of systems or elements that could 
fulfill each function identified as part of the functional area analysis portion of the 
project. Chapter IV will detail the final recommended architecture in a system-of-systems 
context and will further identify a total fleet solution to ensure layered capabilities. The 
fleet solution creates a more robust system that is considered by the team to be capable of 
defeating the identified threat, even under off-nominal conditions. The recommended 
architecture. Option 2, was chosen by considering all technical and operational aspects of 
the problem and identifying risks that result from the implementation of the solution. 

B. ADDITIONAL ARCHITECTURE CONSIDERATIONS 

(LAYERED DEFENSE CAPABILITIES) 

I. Operational Employment 

As described earlier in this report, the team defined a core architecture that could 
defeat the threat set using the existing BMDS assets, while not degrading existing BMDS 
capabilities. As the project progressed, it became clear that a layered defense approach, 
including additional architectures, would be required in order to best defend against the 
unique capabilities of the ASBM threat. The team’s primary approach was to engage and 
destroy the target exoatmospherically to ensure that the target was not able to begin its 
reentry maneuver. The team recognized, however, that additional terminal phase defense 
capabilities should be considered in concert with a midcourse capability, in the event that 
the target is not intercepted in the midcourse phase and reenters the atmosphere. A logical 
consideration for a backup terminal phase intercept capability was the SM-T missile. 
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The team performed a PK analysis to determine the ability of current fleet assets 
to meet the PK requirements of the project. The team analyzed the SM-3, SM-T, and 
mixed-salvo options to determine the PK for each scenario. Due to the classification of 
the data required to compute the PK for both the SM-3 and SM-T, the team used alternate 
analysis techniques to obtain representative data. The techniques included using notional 
timing data for AAW functions of similar systems, including the KA timeline for both the 
Aegis and Zumwalt fire control systems. The team also used engineering-level 
discussions with both Government and contract engineers that are experienced with the 
representative systems to obtain the data needed to assist in the comparative analysis. 
Using the described analysis techniques, the team performed a detailed analysis of the 
effects of multiple CONOPS changes to increase the ability of the concept architecture to 
combat the threat. 

The first CONOPS modification identified was the need to alter the firing policy 
to raise the PK of the exoatmosheperic portion of the engagement. A graphical 
representation of the results of the firing policy vs. PK analysis for both the SM-3 and 
SM-T missiles is depicted in Table 13. The only ordnance currently in the fleet that can 
intercept this threat exoatmospherically is the SM-3 missile; the team initially 
investigated the effects of the firing policy changes using the SM-3 Missile. The SM-T 
portion of the analysis was conducted to determine the feasibility of its use as a 
complementary system to the selected core architecture for a layered defense capability. 
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Table 13. Firing Policy vs. PK Analysis for SM-3 and SM-T Missiles 

Note: The ability to increase the PK by modifying the firing policy or by salvo size is key to 
meeting the required timelines of the ASBMD System. 


Missile 

Type 

PK (Rating) Exoatmospheric 

PK (Rating) Endoatmospheric 

PK (Rating) Mixed 

Shoot 

Shoot-Shoot 

Shoot-Shoot-Shoot 

Shoot 

Shoot-Shoot 

Shoot-Shoot-Shoot 

Shoot 

Shoot-Shoot 

Shoot-Shoot-Shoot 

SM-3 

Fair 

Fair/Good 

N/A 

N/A (Not Capabie of Endo. intercept) 

N/A (Not Capabie of Endo. intercept) 

SM-T 

Poor 

Poor 

Fair 

Good 

Good 

Exceiient 

Depends on the Mix/Not Evaiuated 

*Mixed 

Fair 

Fair/Good 

N/A 

N/A 

N/A 

Good 

Fair 

Fair/Good 

Exceiient 


* Mixed assumes that the first two saivos wiii be SM-3s, and third saivo is SM-T. 


As Table 13 shows, the PK of the concept architecture against the identified threat 
was increased by employing a shoot-shoot firing policy. As a follow-on to this analysis, 
the team also investigated a layered defense CONOPS change using a mixed load-out of 
SM-3 and SM-T missiles. The scenario evaluated called for the ship to perform the initial 
engagement, using a dual-salvo SM-3 policy while the target was still in the 
exoatmosphere and to perform the KA. If a positive no-kill was received, the ship would 
then fire a SM-T as a backup attempt to intercept the target in the upper endoatmosphere 
prior to its terminal phase maneuver. Unfortunately, the analysis performed by the team 
during the AoA phase of this project showed that the time required to perform the KA 
was greater than the available time in this scenario. 

As a work-around to this limitation, the team evaluated the effects of using a 
mixed salvo with a shoot-shoot-shoot-look policy on the PK of the system. The CONOPS 
for this solution would be for the ship to perform an initial dual-salvo SM-3 engagement 
when the threat is at apogee. The system would continue to engage the threat and launch 
an SM-T missile at a time in the engagement window calculated to ensure that the 
intercept would be achieved before the target has begun its final terminal maneuver. The 
team looked at the inclusion of the SM-T as a complementary solution that applies only 
to the Option 2 architecture, since it is not functionally compatible with all candidate 
architectures evaluated during the AoA process. When analyzed, it was determined that 
this layered solution provided a greater probability of mission success at a significantly 
lower cost (refer to Table 13). Although the SM-T is no longer in production, the team 
concluded that the remaining inventory (~ 80 missiles) was sufficient to support the 
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near-term fleet requirements, given the current projected threat production capability 
(Office of Naval Intelligence, 2009, July). Thus, the use of this tactic was the most 
effective and practical fit for the system solution. Note that SM-T performance against 
maneuvering threats has not been assessed and requires additional study. For the 
purposes of this assessment, the assumption was made that the SM-T would intercept the 
threat early in the terminal phase, prior to its maneuver. 

With respect to combat system integration and fire control, the SM-T uses the 
common S-Band missile uplinks for acquisition and midcourse guidance and employs an 
on-board active seeker during terminal phase. This eliminates the need for detailed 
analysis of the capabilities (e.g., range and power) of the MK-99 fire control illuminators. 

2. Additional System Considerations 

The team investigated additional complementary solutions that could be 
integrated with any of the candidate architectures and employed to assist in the 
elimination of the threat. A key operational criterion of the threat group is that it uses a 
global positioning system (GPS) as a guidance source during the midcourse and terminal 
phases of flight. The team investigated use of a GPS transponder, deployed on a vehicle 
in the upper endoatmosphere, to disrupt communication with the combatant's GPS 
satellite and effectively “walk” the threat away from the CSG by feeding the threat bad 
GPS data. Because all GPS variants essentially use the same phase shift keying 
modulation scheme (most are biphase shift keying (bpsk)) and have a similar power 
output, consistent interference techniques could be developed that exploit the reliance of 
a broad range of threats on a variety of GPS systems. Use of omnidirectional GPS 
antennas on the interference source vehicle would help ensure timely acquisition of the 
spoofed GPS signal by the threat. 


74 



Employment of this concept assumes that several conditions would be met: 


• The CSG receives intelligence data indicating a probable or imminent launch, 
and the appropriate mission plan is developed with enough notice to launch 
and position the vehicle. 

• The vehicle is capable of operating in the upper endoatmosphere, has 
sufficient range to reach the required altitude, and can operate in thin 
atmosphere. 

• The vehicle has sufficient endurance to perform loiter maneuvers for a period 
of multiple hours once on station and at the desired altitude. 

• The vehicle is capable of powering the GPS transponder, and the GPS signal 
strength will be greater than that of the combatant's GPS satellite (-130 dBm). 
A moderately higher signal (approximately 20 dB higher) would be sufficient 
to overwhelm the threat GPS signal. 

Once the threat encounters and acquires the false GPS signal, it is anticipated that 
the threat would attempt a course correction. Any course adjustments this late in flight 
would be occurring while the threat is moving very fast. Even if the dummy GPS signal 
were lost and the satellite were reacquired, it is unlikely that the threat would have 
sufficient time to reposition itself to close on the intended target (i.e., a carrier). Eurther, 
the GPS vehicle could be maneuvered away from the flight path once the threat acquires 
the signal, drawing the threat away from the CSG and ideally to a location where it could 
impact the ocean or be put within lethal range of conventional shipboard weapons. 

Other potential options for this concept could include a launch of multiple 
vehicles carrying GPS transponders to create an interference source over a wide 
operational area. Use of multiple Tomahawk Eand Attack Missile (TEAM) vehicles in 
this manner, spread over an operational area with different loiter patterns, would be 
sufficient to disrupt multiple threats. This could potentially increase the coverage area, 
especially if intelligence indicates the likelihood of multiple launches from a single site, 
multiple active sites, or that the active launch units are mobile. This technique may also 
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be effective in dealing with multiple threats launched in a raid configuration and could 
solve the potential discrimination issue of threat evaluation and weapons assignment 
(TEWA) by exploiting the GPS dependency of all threats in the raid. 

Because the vehicle-borne GPS transponder solution was approached as a 
complementary architecture that could supplement any of the possible selected core 
system architectures, it was also desired that the vehicle be a low-cost and easily 
integrated option. Ideally, an existing vehicle that is common to CSGs and could be 
retrofitted with a GPS transponder would be selected for this task. This would add 
additional capability to the system at a fraction of the cost and time required to develop a 
new vehicle expressly for this purpose. 

The team first analyzed the feasibility of using an Unmanned Aerial Vehicle 
(UAV) to fill this role. The MQ-8B Fire Scout UAV was the specific unit considered due 
to the inventory approved for the recent initial deployment on Guided Missile Frigates 
(FFG) and planned deployment on the Fittoral Combat Ship (FCS) and DDG 1000 
platforms. The concept was to launch the UAV well in advance of the arrival of the 
threat; the UAV would loiter in the flight path between the expected launch point and the 
battlegroup while operating the GPS transponder. A graphical representation of this 
concept is shown in Figure 34. 
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Note: The use of a UAV to carry a GPS-interference source across the flight path of the incoming 
threat was analyzed as a potential complementary architecture to augment any of the candidate 
ASBMD architectures. It is shown here in complement to the selected Aegis Combat System 
architecture. 

Figure 34. UAV GPS Interference Option 

This capability appeared feasible, because when the CSG is operating within the 
threat's capability range, the group should have consistent and quality intelligence 
reporting on the anticipated launch sites. The intelligence would allow for advance 
planning and UAV launch staging for faster response and on-station times prior to a 
threat launch. An analysis of this option concluded that the MQ-8B Fire Scout was 
unsuitable for this type of mission since it does not have the capability to achieve and 
maintain the required altitude, due to the environment that the UAV would encounter in 
the upper endoatmosphere. Additionally, the MQ-8B top speed only supports a maximum 
notice scenario. It is unlikely that the MQ-8B could be readied, launched, and positioned 
in time-critical scenarios to support this mission. The lack of widespread fielding or 
available launch platforms for the MQ-8B further limited consideration of it as a viable 
option for this capability. 
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The second option that the team investigated was the use of a TLAM as the GPS- 
transponder vehicle. This option is depicted in Figure 35. 



Note; The use of a TLAM to carry a GPS-interference source across the flight path of the 
incoming threat was analyzed as a potential complementary architecture to augment any of the 
candidate ASBMD architectures. It is shown here in complement to the selected Aegis Combat 
System architecture. 

Figure 35. TLAM GPS Interference Option 

The team concluded that the TLAM option was more technically feasible than the 
UAV option, since the newer TLAM (Block IV)—while not designed for use in the upper 
endoatmosphere—is capable of achieving the desired altitude. The TLAM has a built-in 
loiter mission that can be sustained for as long as its remaining fuel permits. Because the 
TLAM is not designed to operate in the upper endoatmosphere, it would be necessary to 
bring the missile up to the required altitude at a lower speed than typically employed for 
its flyout to minimize the risk of compromising the structural integrity of the missile. The 
ability to have advanced knowledge of the threat launch is again very critical to this 
option. The nominal mission planning and launch time for a new, no-notice mission is 
approximately 10 minutes for a Block IV TLAM. For a predefined Block IV mission 
scenario, the required time is reduced to 5 minutes. Operating at a lower speed, the 
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TLAM could have a nominal flight time of approximately 15 minutes (i.e., a 20-nautieal 
mile (nm) range at a 165,000-foot altitude) to allow the TLAM to be positioned on station 
in time to begin its loiter and disrupt the threat. Although a total, on-station readiness 
window of 20 to 25 minutes is good, this demonstrates the need for intelligenee 
indicators of a pending threat launeh. It is not a viable option for backing up the core 
arehiteeture in scenarios where no advance notice is received. 

3. Fully Integrated Operational Solution (Based on Option 2) 

A graphieal representation of the fully integrated reeommended solution, based on 
Option 2 and ineluding the SM-T and TLAM complementary solutions, is depicted below 
in Figure 36. As diseussed in Chapter III, the fully integrated solution meets the key 
funetional requirements, as well as eost and schedule constraints of the project. 



Note: The fully integrated architecture for the ASBMD system, based on Option 2, includes the 
core Aegis Combat System and the SM-T and TLAM complementary systems. The ability to fully 
integrate these elements into a system of systems is key to mission success in the ASBMD 
scenario. 


Figure 36. Fully Integrated ASBMD System Architecture 
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As depicted in Figure 36, if the equipped ship receives advanced intelligence 
cueing, the crew would create and execute a TLAM mission plan to launch the TLAM for 
the interference mission. If no advance intelligence data were available, the launch of the 
TLAM would not be used as part of the engagement. After launch of the threat, the 
equipped ship would begin receiving BMD data across the BMDS network. The data 
would include a composite system track that is made up of fused Link-16 and CEC data 
from remote, forward-based sensors. Since the fire control algorithms have been 
optimized, the Aegis Weapons Control System (WCS) would recommend a launch time 
that would ensure that the time to intercept of the first dual-salvo SM-3s would be at the 
point that the threat has just reached apogee. This optimization is key to mission success 
since it ensures that the threat is intercepted at the point in flight where the target presents 
the largest cross section before the SM-3 intercepts. 

Upon launch of the first salvo of SM-3 missiles, the ship would begin planning 
the launch of the second salvo, consisting of the SM-T interceptor to ensure the layered 
defense capability that was described in section 2 of this chapter. As the first salvo of 
SM-3 missiles breaches the atmosphere, the TLAM would begin transmitting GPS 
interference along the flight path of the threat. Ensuring that the SM-3s have exited the 
atmosphere before initiating the GPS interference is critical to mission success, since the 
interference could also impact the guidance of the SM-3. Prior to the actual engagement 
of the first salvo of SM-3, the updated Aegis fire control system would determine a need 
to launch the SM-T missile and ensure intercept in the upper endoatmosphere before the 
threat has begun its terminal maneuver. Upon engagement of the threat by the first salvo 
(i.e., dual-salvo SM-3s), the system would use both organic and BMDS nonorganic data 
to perform a KA. If the KA returns a positive kill, the threat has been eliminated, and the 
fire control system would terminate the SM-T portion of the mission and self-destruct the 
SM-T missile. The mission would be considered complete. If the system determines that 
the threat remains active, a status of no-kill would be reported, and the system would 
continue to consummate the SM-T portion of the engagement sequence. This weapon 
requires organic radar control commands until the threat’s terminal phase of flight. 
Therefore, resources would be prioritized to ensure sufficient guidance could be provided 
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until the SM-T is within range of the threat. Following the SM-T engagement, the same 
KA described above would occur. 

Although the specific firing policy updates to the CONOPS are not employed 
today, the selected system solution would be compatible overall with current fleet 
CONOPS and could be implemented with minimal impact and additional resources. The 
current fleet CONOPS provides for at least one BMD-equipped Aegis cruiser or 
destroyer within each CSG. Implementation of the ASBMD architecture would not 
change the current CONOPS but would require that the Aegis ship be equipped with the 
recommended system solution. The operational implementation of this system would 
include the plan to backfit the current BMD-equipped Aegis cruisers and destroyers to 
ensure a sufficient number would be available to support the CSG CONOPS. The 
ASBMD capability should be fielded in accordance with the BMD baseline installation, 
fielding, and maintenance plan so that the system could be deployed at minimal cost. If 
desired, the ASBMD architecture could be backfit in additional ships as new BMD ships 
are brought online, in accordance with the baseline installation schedule. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. OVERVIEW 

The ASBMD team applied and maintained compliance successfully with a 
rigorous, tailored systems engineering process. The team created and followed a 
comprehensive and challenging schedule to ensure that research and development of the 
ASBMD System solution met the timelines identified at the beginning of the project. As 
defined in Chapters II and III, the team followed a tailored version of the systems 
engineering “V” model and focused on creation of a key set of analysis artifacts and 
program documentation. The objective was to design and communicate a robust system 
architecture that could fill the capability gap created by the introduction of the ASBM 
threat set. 

Following requirements analysis and functional decomposition, the team 
developed and analyzed eight core system solution candidates and two possible 
complementary solutions. Using the key system requirements and schedule constraints as 
the bounding factors for the solution space, the team was able to quickly narrow the 
concept architectures down to three. Through the process of technical feasibility 
screening, the team was able to determine the single, best fit architecture concept, as 
described in Chapter IV. The recommended solution is based on Option 2 and includes 
the layered defense capabilities provided by the complementary SM-T and TLAM 
systems, as shown below in Figure 37. 
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Note: The fully integrated architecture for the BMDS system, based on Option 2, includes the core 
Aegis Combat System, as well as the SM-T and TLAM complementary systems. The ability to 
fully integrate these elements into a system of systems is key to mission success in the ASBMD 
scenario. (This figure was previously presented as Figure 36.) 

Figure 37. Fully Integrated ASBMD System Architecture 

These analyses focused on maximizing the detection and tracking capabilities of 
the selected architecture. The maximization of the detection and tracking ranges 
lengthens the engagement window and ultimately increases the ability to protect the 
CSG. Using the core architecture, as described in Chapter IV, provides the ability to 
deploy quickly, enhance the capability of the BMDS, and use existing assets without 
major modification to the current fleet CONOPS. The core option also has negligible 
impact to the total lifecycle cost of the existing systems, since it can be provided as an 
upgrade to the current fielded assets and then installed during the next scheduled 
installation and checkout (INCO) or maintenance availability. 

The complementary systems defined in Chapter IV, if implemented as designed, 
would have negligible impact to the current BMDS network, but would require a fleet 
CONOPS update to facilitate the early warning and launch requirements to support the 
use of the system as described. The total lifecycle cost of the existing weapon system 
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would still be unaffected with this solution, since the capabilities already exist within the 
current fielded assets. 

B. FOLLOW-ON RECOMMENDATIONS 

The recommended core architecture was paired with two complementary 
architectures, SM-T and GPS, to further layer the defensive capability of the ASBMD 
system. While both of these complementary concepts were deemed feasible by the 
ASBMD team for application in this manner, this determination was made via 
engineering assessment and has not been demonstrated through detailed analysis or test. 
No performance characterization has been conducted for either technology in this 
scenario; however, further study of both applications for consideration in a BMD 
architecture is recommended. 

In addition to the ASBMD team’s recommended solution, the team also 
recognized that it would be beneficial to continue to pursue the long-term development 
and testing of Option 1, as defined in Chapter III. Pursuit of Option I would ensure that 
the latest technology is developed with the ASBMD mission in consideration and would 
extend the fleet’s ability to combat the ASBM threat with future platforms. As discussed 
in Chapter III, the SPY-3 radar would advance search and track capabilities beyond that 
of the SPY-1 radar currently employed in the Aegis Combat System. The Zumwalt 
Combat System would also bring advanced tracking and discrimination algorithms into 
service and will provide additional capability that would assist in lengthening the 
battlespace and engagement timeline for the ASBM threat. 

The cost analysis for Option 1 was included in Chapter IV. Since the Zumwalt 
program is already under development and is currently funded through its IOC, an 
ASBMD capability for Zumwalt would need to be added to the Zumwalt Combat System 
and SPY-3 Radar. This would require additional funding, but could be integrated prior to 
IOC at a lower cost than if the decision to implement this capability in Zumwalt is made 
following delivery of the platform. 
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1 INTRODUCTION 

1.1 PROJECT DESCRIPTION 

The members of this team have been tasked with investigating a system solution 
to counter the evolving Land-Based Anti-Ship Ballistic Missile threat. Current reports 
indicate that multiple countries and organizations have funded research and development 
of missile systems specifically designed to target sea-going vessels, including U.S. 
warships and aircraft carriers. This plan identifies the key tasks that the team will 
accomplish to research and identify a recommended architecture for a robust system of 
systems solution that may be developed to counter such threats. 

1.1.1 Problem Statement 

A recent article in the U.S. Naval Institute’s Proceedings Magazine has suggested 
that China is developing ballistic missiles that can be used against moving targets, such 
as ships. One such technology is said to be able to cover a range of 2,000 kilometers (km) 
and operate at a speed of Mach 10. This type of threat from China, or any other nation, 
could greatly impact the current concept of operations of U.S. Navy ships. While there 
are currently some individual solutions capable of providing partial defense in specific 
mission scenarios, no comprehensive system has been developed to counter this threat 
post-launch. To fulfill this need, the Anti-Ship Ballistic Missile Defense (ASBMD) team 
will propose a notional architecture for a system of systems that could be used to 
effectively counter this threat. 
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Figure A-1. Modern Carrier Strike Group Underway 
[From Strategypage.com, 2008] 

1.2 ORGANIZATION STRUCTURE 

The ASBMD team has decided to structure ourselves into Integrated Product 
Teams (IPTs), headed by a Team Lead. Each IPT Lead is a member of the Overarching- 
Level Integrated Product Team (OIPT) headed by the Project Manager (PM). This 
philosophy is expressed pictorially below in Ligure A-2. The IPT structure directly maps 
to the Systems Engineering approach that we have chosen. The Systems Engineering 
philosophy will be discussed later in this document. IPTs will be established as necessary 
to perform the analysis and meet project objectives within each project phase. As an IPT 
completes its assigned tasking, the IPT Lead will report out to the OIPT/PM and 
members will populate or update their portion of the Capstone report. Upon completion 
and review of the relevant sections of the Capstone report, the IPT team members will be 
reassigned as necessary to support other tasking. The OIPT is responsible for identifying 
the Working IPT (WIPT) requirements throughout each project phase. 
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Figure A-2. ASMBD OIPT Structure 
1.2.1 Team Membership 

Table A-1 provides the names and contact information for each of the ASBMD 
team members. 


Table A-1. ASBMD Team Member Contact Information 


Name 

Organization 

E-mail 

Phone 

Role 

Hobgood, Jean 

NSWCDD/K54 

jean.hobgood@navy.mil 
(540) 653-2968 

Technical Editor, 

Risk Manager 

Madison, Kim 

NSWCDDAV63 

madisonkg @ gmail. com 
(540) 653-6745 

Data Librarian 

Nedd, Steven 

TACOM 

steven.nedd@us.army.mil 
(584) 574-7928 

Modeling Specialist 

Pawlowski, Geoff 

NSWCCD2110 

geoffrey .pawlowski @ navy.mil 
(301) 227-3661 

Cost Analyst 

Roberts, Michael 

NSWCDDAV51 

michael. w.roberts @ navy.mil 
(202) 406-4250 

Lead System Analyst 

Rumberg, Paige 

NSWCDD/Q51 

paige .rumberg @ navy.mil 
(540) 653-3478 

Team Lead, Scheduler 
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2 SYSTEMS ENGINEERING APPROACH 


2.1 OVERVIEW 

A tailored Systems Engineering Process (SEP) will be utilized in the performance 
of this Naval Postgraduate School (NPS) Capstone Project. The SEP process chosen by 
the ASBMD team will be based on the V model, one of the SEP frameworks outlined in 
the NPS System Engineering Curriculum. A representation of the V model being used by 
the ASBMD team is shown in Eigure A-3. 
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Figure A-3. ASBMD SEP Approach 
2.2 TEAM APPROACH 

The tailored version of the V model, shown in Figure A-3, will be used by our 
team to develop a notional system architecture that can be used to effectively defend 
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against anti-ship ballistic missiles. At a fundamental level, the rationale for using a 
Systems Engineering V process is founded on the idea that it can provide an organized 
approach to problem resolution, according to the Sage and Armstrong text. Introduction 
to Systems Engineering. 

The focus of this project, as our team has defined it, will be to address the 
Concept Refinement phase of the Defense Acquisition Process. Specifically in this phase, 
we will be focusing on developing high-level Concept of Operations (CONOPS), 
requirements, and system-level architecture artifacts. We feel that the SEP V process is 
appropriate for our use, because the project focuses on performing early acquisition phase 
conceptual definition and the supporting functional analysis. 

2.2.1 Initial Research 

With the problem statement identified during the initial phase of the project, and 
the overall goal of the project outlined, the initial research will be conducted covering all 
aspects of the problem. The team will be leveraging both public domain documentation 
and personal experiences to understand the detailed functional aspects of the problem. 

The team will research the capabilities and functional makeup of the basic threats that 
were identified in the initial problem statement. Understanding the threats and existing 
system capabilities will assist us in defining the system that can effectively combat the 
threats. Each of the topics chosen will be related to the SEP to ensure that the boundaries 
of the problem statement are maintained. 

2.2.2 Stakeholder Analysis 

During the stakeholder analysis phase, the individuals with a vested interest in a 
system that can achieve the objectives described in the problem statement will be 
identified and categorized according to their influences on the system. The output of this 
phase will be a weighted scale that will ensure that stakeholder needs have precedence in 
the decision-making process. Stakeholder inputs will be collected by surveys, interviews, 
or focus groups; these inputs will be used to derive system requirements and needs. The 
team will use the Quality Eunction Deployment (QED) model and/or Pareto Analysis to 
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both ensure that the customer inputs are understood, and to prioritize inputs so that the 
most significant issues are examined. Weighting of system requirements will allow the 
team to tailor the analysis phase so that only the most viable alternatives are evaluated. 

2.2.3 Problem Formulation 

In this phase, the project team will refine the problem definition to confirm that it 
remains scoped within the timeline and boundary of the project as we have defined it. 
This process will involve the performance of functional analysis to understand what the 
system must accomplish, and the development of a functional architecture that outlines 
the sequence and structure of the tasks identified during functional analysis. 

2.2.3.1 Perform Functional Area Analysis 

As stated in Blanchard and Fabrycky’s Systems Engineering and Analysis, the 
functional area analysis portion of any system engineering process is a critical step. In 
this task we will use the functional need statement, derived from the stakeholder analysis 
performed in earlier steps, to define the system needs and basic requirements from the 
system level down to the applicable level of detail. Per the direction provided during the 
NPS Systems Engineering curriculum, the objective of functional analysis is to specify 
the “what’s” that need to be accomplished. We plan to use Figure A-4 as a starting point 
for our functional hierarchy. This notional functional hierarchy will be updated to depict 
the overall actions required to effectively and efficiently meet the threat detailed in the 
problem statement. As discussed earlier, this functional hierarchy is notional and will 
change as the team further defines the scope of the project. 
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Figure A-4. ASBMD Functional Hierarchy (Notional) 

2.2.4 Analysis of Alternatives 

Upon completion of the problem formulation and the functional architecture 
determination described above, our team will determine the physical architectures and 
generate various system alternatives. During this phase, the team will also begin 
developing the models that will be used to analyze the various alternatives of the system. 
This work will help drive the feasibility analysis and metrics that will be used in the 
justification for a final recommended decision. 

2.2.4.1 Developing Alternatives 

Morphological charts and the QFD diagrams created earlier will be used to assist 
the project team in the development of alternatives. This is the point in the process where 
the “what’s” are developed into “how’s.” 
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2.2A.2 Generate Metrics to Measure Effectiveness/Performance 

During this activity, the team will be generating metrics as we compare the 
alternative systems defined during the Analysis of Alternatives phase to both the 
operational- and performance-related requirements. The objective of the developed 
metrics will be to provide quantitative evaluation of the effectiveness and performance of 
the various alternatives. The outcome of this effort will be a measurement of how 
completely each of the alternatives meets the defined performance requirements. 

2.2A.3 Develop Models and Simulations 

During this task, the team will develop models and simulations using different 
modeling techniques for the purpose of evaluating tangible alternatives and as a method 
of understanding the system of systems, functional decomposition, hierarchy, and overall 
system effectiveness. Furthermore, Arena, Excel, MATLAB, UML and other tools will 
be used throughout the design process to assess risk, cost, schedule, and system 
performance. The goal is to produce a system architecture that can provide a solution to 
the problem statement that best meets the needs identified from the stakeholder analysis. 

2.2.5 System Concept Refinement/Finalization 

The final phase of our modified SEP is to perform System Concept Refinement 
and Einalization activities. The goal for this phase is to carry out the final decision 
analysis of the alternatives with reference to the Measures of Effectiveness (MOEs) and 
Measures of Performance (MOPs) obtained from metrics analysis and the modeling and 
simulation exercises. It will involve cost analysis, risk analysis, sensitivity analysis, 
trade-off study, and finally, the recommendation of the preferred alternatives. 

2.2.5.1 Cost Analysis 

The goal for cost analysis is to estimate the total Eife Cycle Cost (ECC), or Total 
Ownership Cost (TOC), of the various identified alternative systems. The ECC is defined 
as the cost of the Research, Development, Test, and Evaluation (RDT&E); procurement 
of prime equipment, support equipment and spares; operations and support of prime 
equipment, support equipment and spares; and disposal of the system. Out year costs will 
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be discounted to reflect the declining value of the dollar over time and allow alternatives 
to be compared to one another using net present value. 

2.2.5.2 Risk Analysis 

Risk analysis will be conducted to identify the risk drivers associated with 
developing this Capstone project. The goal is to identify cost, schedule, and technical 
risks so that they can be controlled, and that the consequences of courses of action can be 
determined as early in the process as possible. The ASBMD team will perform this risk 
management during all phases of the development of our project. All risks that we 
identify will be analyzed and scored according to risk management procedures defined in 
the DoD Risk Management Guide (RMG). All risks are evaluated and categorized 
according to the probability (likelihood) of failing to achieve a particular outcome and the 
consequences (impact) of failing to achieve that outcome. 

Initial risk analysis performed by the ASBMD team has identified six current 
risks. Four of these risks are related to meeting our project schedule and two are related 
to being able to find a feasible technical solution. An Excel spreadsheet is maintained by 
the team and contains a current status of all risks being tracked by the team and the 
mitigation plans for each one. Figure A-5 shows the current risk matrix for the ASBMD 
team. 



Figure A-5. Current ASBMD Risk Management Matrix 
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Table A-2 describes the risks currently being tracked by the team. 

Table A-2. Current Risk Description for ASBMD 


Risk# 

Description 

Type 

1 

The team will not be able to generate a list of viable alternatives to 
counter the threat in a timely manner, so the analysis of alternatives 
will be delayed. 

Schedule 

2 

The team will not decide on a list of Key Performance Parameters 
(KPPs) in a timely manner, so the analysis of alternatives will be 
delayed. 

Schedule 

3 

Modeling and simulation tools will not be developed in time for 
their use in the analysis of alternatives. 

Schedule 

4 

Final project report and briefing will not be completed on time. 

Schedule 

5 

The team will not be able to find a feasible solution to meet the 
stated need. 

Technical 

6 

The chosen solution is not able to be integrated with existing 
systems. 

Technical 


2.2.5.3 Sensitivity Analysis 

A basic sensitivity analysis will be conducted to verify the quality of the 
mathematical models. The assigned weights used for decision-making criteria will be 
varied to determine the areas that are the most influential in the outcome of the system 
decision. Sensitivity analysis will identify the sources of uncertainty that affect the 
study's conclusions most. This will ensure the quality of the models and increase 
confidence in the assessment. 

2.2.5.4 Trade-off Study 

A trade-off study is the activity of finding the solution to a problem that best 
satisfies a series of technical measures and/or cost functions. These measures will 
describe the desirable characteristics of a given solution. Multiple Criteria Decision 
Making (MCDM) methodology such as min-max methods, min-max regret methods, and 
weighting methods (decision matrix), may be used to compare each of the alternatives. 
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3 MILESTONES AND DELIVERABLES 


3.1 OVERVIEW 

As described above, when using the SEP approach there are several key 
milestones and associated deliveries that the team will need to make to ensure that 
progress is being made. As detailed in section 2.2, this project will focus on the Concept 
Refinement Phase of the Defense Acquisition Process. The ASBMD team will create 
high level excerpts from each of the key documents identified in the Integrated Defense 
Acquisition, Technology, and Logistics Life Cycle Management Evolutionary 
Acquisition Program, using the DoD Instruction 5000.2 as the guide. The high level view 
of the Defense Acquisition Process focusing on the areas that we are going to address is 
shown below in Ligure A-6. 


User Needs & 
Technology Opportunities 




Concept 

Refinement 



Concept 

DecHlon 





Figure A-6. ASBMD Focus within the Defense Acquisition Process 
[Lifecycle Framework View] 

3.2 DELIVERABLES 

The following products will be provided by the ASBMD team for this Capstone 
project as a stand-alone document as well as being excerpted in the team’s final report: 

• Problem Statement: Statement outlining the current system capabilities and 
threat assessments; provides details of the current system functional gap that 
our team has chosen to address. 
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• Project Management Plan (PMP): Initial project guide that will shape our 
teams approach and schedule for developing the project documentation. 

• Stakeholder Analysis: Results from the QFD and/or Pareto Analysis. 

• CONOPS (Excerpt): Describes the concept of operations for our project; 
also, the beginning of how we plan to fit our solution into the existing systems 
within the fleet. 

• Functional Area Analysis: Identification of operational tasks, conditions, and 
standards needed to accomplish the system objectives. 

• Functional Architecture (Department of Defense Architecture 
Framework [DoDAF] products): High-level functional diagrams depicting 
the overall system alignment and functions from a system view. Also, details 
interactions within the system and identifies the key functions that are 
performed. 

• Initial Capabilities Document (ICD) (Excerpt): As defined in the Chairman 
of the Joint Chiefs of Staff Instruction (CJCSI) 3170.01F, Joint Capabilities 
Integration and Development System (JCIDS). This will be the main 
deliverable for the system engineering effort of our project. The ICD will be 
used to identify the KPPs and Key System Attributes (KSAs) which define the 
most critical elements of performance for our system. This document will be 
closely tied to the CONOPS; this is done to ensure that the KPPs identified 
meet the overall need of the system as originally defined during the analysis 
phase. 

• Analysis of Alternatives Results: These will be used to evaluate each of the 
possible system combinations. This analysis will take into account the ability 
of the alternatives to meet KPPs and KSAs as well as affordability and 
schedule constraints. 

• Metrics, Models and Simulation Analysis: Used to detail the models and 
associated metrics that will be used to validate the chosen systems 
performance to ensure it meets MOEs and KPPs. 
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• Final Report: Collection of the artifacts that were delivered earlier in the 
project. The final report will be the documentation of the final process and 
schedule that the team used to assess and present the recommended system 
architecture. 


3.3 SCHEDULE 

The overall schedule for the analysis and delivery of the key work products is 
outlined in Figure A-7. 



Figure A-7. ASBMD Current Project Schedule 
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ABBREVIATIONS AND ACRONYMS 


ASBM 

Anti-Ship Ballistic Missile 
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Anti-Ship Ballistic Missile Defense 
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Battle Management Command, Control, Communications, 

Computers, and Intelligence 
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Ballistic Missile Defense 
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Ballistic Missile Defense System 
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Command and Control, Battle Management and Communications 
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1 ANTI-SHIP BALLISTIC MISSILE DEFENSE CONOPS 

1.1 Objective 

The objective of the Anti-Ship Ballistic Missile Defense (ASBMD) system is to 
detect, track and eliminate Anti-Ship Ballistic Missile (ASBM) threats. The team will 
research and document a proposed architecture for a total system solution that could 
potentially be used to combat the evolving ASBM threats. 

1.2 Assumptions 

The following list of assumptions will apply to this document and all follow-on 
efforts for this project: 

• ASBM threats will be launched from land. 

• All current communication mechanisms are operational and deployed on all 
systems. 

• While used for Ballistic Missile Defense (BMD), the system will not be 
required for additional functions. 

1.3 Scope 

This document outlines the ASBMD Concept of Operations (CONOPS) for 
support of the Team 1 Master of Science in Systems Engineering (MSSE) Capstone 
project. The system under investigation is limited to the specific scope that has been 
defined in the problem statement and detailed in the Project Management Plan (PMP) 
created earlier in the project. The scope of the project includes the research, creation and 
documentation of the total system architecture that may be used to combat the identified 
threats. The system is limited both by the assumptions outlined in Section 1.2 and by the 
constraint that it must communicate and integrate into the existing Ballistic Missile 
Defense System (BMDS). 

Due to the maturity of existing capabilities to detect and track ballistic missiles 
during the boost phase, the ASBMD team will primarily focus the detailed analysis and 
architecture documentation on the post-boost phase - tracking and eliminating the threats 
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during later phases of the ballistic flight-path. Figure B-1 depicts the basic stages of flight 
of a nominal ballistic missile. 



Figure B-1. Phases of Ballistic Missile Flight 
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2 SYSTEM NEED 


2.1 Problem Statement 

Recent intelligence reports have suggested, as described recently in U.S. Naval 
Institute’s Proceedings Magazine, that multiple nations are developing ballistic missiles 
that can be used against moving targets, such as ships. These threats are being 
increasingly characterized as having the ability to maneuver for evasion and to track their 
targets during the terminal phase of the ballistic missile flight path, as depicted in 
Figure B-2. One such technology is said to be able to cover a range of 2,000 kilometers 
(km) and operate at a speed of Mach 10. This type of threat could greatly impact the 
current CONOPS of U.S. Navy ships. While there are currently BMD solutions that can 
intercept threats in the midcourse and terminal phases, no comprehensive system has 
been developed to counter a maneuvering reentry vehicle threat post-launch. Figure B-3 
demonstrates the potential range for these threats if launched from mainland China. 



launch site 


carrier when the 
missile was launched) 


of the aircraft 
carrier with mid 
segment guidance) 


Figure B-2. Notional Operation of ASBM Threat 
with Maneuvering Reentry Vehicle 
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Figure B-3. Map of China and Overlay of Missile Ranges 
2.2 The Ballistic Missile Flight 

Intercepting a missile in its boost phase is the ideal solution for ballistic missile 
defense. If the missile is carrying a chemical, biological, or nuclear weapon, the debris 
will most likely fall on the country that launched the missile. At the least, it will certainly 
not have obtained enough velocity to reach its intended target. Because of this, it is not 
critical to completely destroy the missile’s warhead. Although attacking a missile while it 
is struggling against the earth’s gravity is ideal, it poses significant challenges to a 
defense system. First, the boost phase is relatively short. This means that sensors will 
have to detect a launch and relay accurate information about the missile very quickly. 
Second, an interceptor missile would have to be very close, or extremely fast to catch up 
to the accelerating missile, and properly configured to intercept a target in the boost 
phase. When possible, for the global coverage and protection against more lethal 
payloads it can provide, a capability to intercept a missile near its launch point is always 
preferable to attempting to intercept that same missile closer to its target. 

The midcourse phase allows the largest opportunity to intercept an incoming 
missile. At this point, the missile has stopped thrusting, so it follows a more predictable 

path. Depending on the interceptor launch location, multiple interceptors could be 

122 









Appendix B 


launched, with a delay between them to see if the first ones were successful. Since the 
interceptor has a longer time to engage, fewer interceptor sites are needed to defend 
larger areas. Unfortunately, a longer period in space provides an attacking missile the 
opportunity to deploy countermeasures against a defensive system. However, the 
defensive system also has more time to observe and discriminate countermeasures from 
the warhead. 

The terminal phase of a ballistic missile’s flight is normally less than one minute 
long. At this point, defensive systems must be very close to the missile’s target in order to 
defend against the attack. Countermeasures are less of a challenge in this phase. They 
usually fall slower than the warhead and are burned up as the warhead re-enters the 
atmosphere. Defensive systems designed for the terminal phase are most effective in 
protecting nearby troop concentrations, ports, airfields, and staging areas. Currently 
fielded terminal phase interceptors have not been proven to be effective against 
maneuvering re-entry vehicles. 

2.3 Existing Capabilities 

There are currently multiple systems deployed that are designed to combat 
Theater Ballistic Missiles. Each of the individual systems are designed to focus on 
specific phases of the ballistic missile flight as described in section 2.2. Some examples 
of these systems and their primary functions are described in Table B-1 below. 
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Table B-1. Existing Systems, Time Phase, and Function 



System Name 

Phase 

Function 

Weapon Systems 

Ground Based Interceptor (GBI) 

Midcourse 

Engagement 

Patriot Advanced Capability-3 (PAC-3) 

Boost/Midcourse 

Engagement 

Standard Missile (SM)-3 Block lA 

Midcourse 

Engagement 

SM-2 Block IVA (SMT) 

Terminal 

Engagement 

Terminal High Altitude Area Defense 
(THAAD) 

Terminal 

Engagement 

Sensors 

Cobra Dane Radar 

Boost 

Detection/Tracking 

Ultra Early Warning Radar (UEWR) 

Boost 

Detection/Tracking 

AN/TPY-2 (Eorward-Based Mode) 

Boost 

Detection/Tracking 

AN/TPY-2 (THAAD Mode) 

Terminal 

Detection/Tracking 

AN/SPY-1 

Midcourse/Terminal 

Detection/Tracking 

Space-Based Sensor Suite 

Boost/Midcourse 

Detection/Tracking 

Sea-based X-band Radar (SBX) 

Boost/Midcourse 

Detection/Tracking 

BM C4I 

Command and Control, Battle 

Management and Communications 
(C2BMC) Spiral 6.2 

All 

BMC4I 


A specific example of such a system includes the successful Aegis BMD System. 
This specific system uses both remote and local detection and tracking via ground and 
satellite based sensor systems and shipboard sensors. Once the threat has been detected 
and transitioned to track, the remote systems can “hand over” the threat track to the 
shipboard AN/SPY-ID Radar System for organic tracking and engagement. The 
handover of the threat is accomplished by having the remote tracking system calculate a 
flight trajectory of the threat track and cue the organic radar to a point in space where the 
threat will be at a given time. This method requires direct high speed communication 
between all elements in the system. The Aegis BMD systems also rely heavily on the 
availability of the SM-3 or SM-2-Block IVA missile to engage and destroy ballistic 
targets in the midcourse and terminal phases, respectively. The systems currently have no 
alternate or complementary shipboard weapons that could be used to combat a ballistic 
threat. 
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System Configuration — 2007 
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Figure B-4. Missile Defense Agency (MDA) Ballistic Missile Defense System, 

as of 2007 

As discussed earlier in this document, there are multiple systems currently 
deployed or in development that have the ability to detect and track ballistic missiles 
during boost, midcourse, and terminal phases. Coupled with the existing system that 
provides the capability to engage these threats during the same phases, the U.S. has a 
robust system design that has a successful track record during test intercepts of ballistic 
targets. 
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3 SYSTEM JUSTIFICATION 

3.1 Current System Shortcomings 

3.1.1 Sensors 

As previously described, the current BMDS rely heavily on the ability of remote, 
internal, and onboard sensors to predict and relay the flight path trajectory of the ballistic 
threat. The anti-ship threats that are being introduced have uncovered a major shortfall in 
the current deployed systems. Using the example threat given in the problem statement, 
upon re-entry the threat can be traveling in excess of Mach 10 and can maneuver during 
the terminal portion of flight, altering its aim-point and ultimately forcing a defense 
system to estimate a false trajectory. Given the current capabilities, the ability of the 
system to predict the flight path of these threats becomes impossible. 

3.1.2 Weapon System 

Another shortcoming of the current system is that, for sea-based intercepts, it 
relies exclusively on the availability of ships configured with the Aegis BMD Weapon 
System and loaded with SM-3 or SM-T missiles. Only 5 cruisers and 16 destroyers are 
configured to conduct Aegis BMD missions, so these assets must be strategically located 
to provide adequate coverage. While the SM-3 Block lA is a full rate production missile, 
it is only capable of conducting midcourse intercepts. The Sea-Based Terminal (SBT) 
terminal-phase intercept capability is provided by use of the modified SM-T. Since this 
missile is no longer in production, the SBT capability is limited to the remaining 
inventory of this missile. Given the minimal system availability, there exists a very large 
operational risk for most carrier battle groups. Based on the capabilities deployed to-date, 
if the threats that we have identified are put into production, there would need to be a 
very large shift in the current operational CONOPS for the U.S. Navy. Without a robust 
and reliable system to counter these threats, U.S. Navy Carrier Ships would be required 
to drastically reduce their ability to operate within close vicinity of countries that have the 
threat production capabilities. 
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3.2 New System Benefits 

The system architecture that the ASBMD team will be producing will document a 
system that will eliminate the ASBMD threat by using remote data for tracking and 
engagements. The specific benefits of the ASBMD System will be its ability to track and 
eliminate or avoid maneuvering threats during the midcourse or terminal phases of flight. 
The Navy will benefit from a robust architecture that can provide engagement-quality 
data to a system that can be used to eliminate the threat during the terminal phase of 
flight. 


3.3 Priority of New Features 

The ASBMD team has prioritized the key system features taking into 
consideration existing systems that can perform portions of the mission. As stated earlier, 
there are multiple systems that have the ability to detect and engage ballistic missiles 
during the boost phase of ballistic missile flight, therefore the priority of our proposed 
system and analysis will be the tracking and engagement of anti-ship ballistic missiles 
during the midcourse and terminal phase of flight. 

Within the terminal phase of flight there are two key features, tracking and 
engagement, and we have prioritized these functions as well. The ASBMD team 
prioritized tracking of the re-entry vehicles as the highest priority and then the 
engagement of the threats as the second highest. This prioritization is based on the fact 
that the ASBMD System is predicated on the ability of the system to provide engagement 
quality data that may be used to engage and eliminate the threats; therefore, tracking of 
the threats is of the utmost importance. 
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4 FUNCTIONAL REQUIREMENTS 

Discussions with stakeholders resulted in high level operational requirements that 
will be used as a starting point for further analysis and decomposition. The list is subject 
to change as feedback is generated in subsequent systems engineering steps. A complete 
final list will be documented in the ASBMD Initial Capabilities Document (ICD). 

1) ASBMD System shall be capable of sending, receiving, and processing 
intelligence reporting messages to be used for situational awareness related to 
Ballistic Missile flight path. (Includes but not limited to the ability to receive 
and process Global Command and Control System Maritime (GCCSM), Link- 
16 Tactical Digital Information Link (TADIL-J), N-Series Messages, and 
J-Series Messages). 

2) ASBMD System shall process received intelligence messages and create radar 
search sectors to be used by both on-board and off-board sensors. 

3) ASBMD System shall detect and track Ballistic Missiles including up to 

10 vehicles during terminal phase of missile flight path. Tracking shall include 
the production and dissemination of engagement quality data. 

4) ASBMD System shall be capable of near simultaneous engagement of no- 
less-than 10 ballistic vehicles. 

5) ASBMD System shall be capable of performing “Launch on Remote” using 
fire control quality data from the BMDS network. 

6) ASBMD System shall have the ability to perform both self-defense and BMD 
missions. 

7) ASBMD System shall have a Mean Time Between Failures (MTBF) that is 
greater than or equal to the MTBF of the existing BMDS System. 

8) ASBMD System shall have the ability to perform high fidelity object 
discrimination. 
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9) ASBMD System shall have the ability to perform localization. 

10) ASBMD System shall have the capability to perform threat identification. 

4.1 Mission Features Capabilities and Functions 

4.1.1 System Components and Functions 

The ASBMD capability will be achieved by a system of systems that, to meet its 
mission requirements, is comprised of a minimum set of components. Components that 
will be considered and analyzed may include: radar, electro-optic (EO)/infrared (IR) 
sensors, passive electronic warfare sensors, communications/link architecture, command 
and control, decoys, electronic countermeasures, and weapon system. 

A preliminary functional analysis has resulted in a list of the primary system 
functions, as follows: 


• Search: The system will be capable of conducting search functions in 
self-defense and BMD modes. 

• Detect: The system will be capable of detecting an incoming threat 
organically (using own-ship sensors). The system will also be capable of 
initiating engagement sequences based on remote sensor detection and hand- 
off of track. 

• Acquire Track: The system will be capable of conducting organic track 
acquisition and communicating that track to the BMDS. The system will also 
be capable of a launch on remote track data, with eventual acquisition of the 
track organically, or full engagement on remote track data (with no organic 
track acquisition). 

• Planning: The system will be capable of communicating with BMDS 
resources for determination of the best use of local radar and weapon 
resources. 

• Identification: The system will be capable of identifying the threat type and 
not engage on countermeasures, within margin, via onboard sensor 
discrimination. 

• Engagement: The system will be capable of executing an engagement against 
the incoming threat. 
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• Kill Assessment: The system will provide kill assessment data to the operator 
and the BMDS so that a determination of kill and potential for re-engagement 
can be assessed. 

4.1.2 Operational Environment 

The system must be capable of surviving and operating in the tactical 
environment and will meet all requirements for system certification and fielding. Ships 
with this capability can be deployed in any operational area necessary to provide 
coverage in the ASBMD mission area. 

4.1.3 System Interfaces 

The system, as designed, must interface with the larger BMDS for the purposes of 
battle management, data sharing, and command and control. It will interface with its 
battlegroup or ships in company for local and remote fire control, radar resource and 
weapon management. 
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5 CONCLUSIONS 

Currently there is no single solution to address the threat described in the problem 
statement. In designing a system of systems solution, a key objective of this project will 
be to consider technologies that would complement a layered approach that takes 
advantage of remote and forward-based capabilities as well as organic/own-ship 
capabilities. Any leveraging of existing technology will require that the systems are made 
more robust to meet requirements for sensor function, detection, and BMDS interfaces. 
The final product of the system design will be to propose a reliable, compatible, and 
interoperable ASBMD functionality to support defense of critical assets and mission 
areas to the U.S. Navy. 
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ABBREVIATIONS AND ACRONYMS 


ASBM 

Anti-Ship Ballistic Missile 
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Anti-Ship Ballistic Missile Defense 
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Ballistic Missile Defense System 

C2 

Command and Control 
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Concept of Operations 
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Initial Capabilities Document 
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1 SCOPE 

The proposed Anti-Ship Ballistic Missile Defense (ASBMD) System is scoped to be a 
system of systems that provides a set of value-added functions that will be operated within the 
existing Ballistic Missile Defense System (BMDS). The system’s objective is to provide 
increased capabilities to defend against and eliminate Anti-Ship Ballistic Missile (ASBM) 
threats. The proposed system will be fully integrated, interrelated, and interoperable with the 
existing BMDS. As a result, the ASBMD System will be an information environment within an 
existing combat system comprised of interoperable computing and communication components. 
As originally defined in the ASBMD Concept of Operations (CONOPS), the ability of an ASBM 
threat to maneuver during its ter mi nal phase of flight is what differentiates it from the average 
ballistic missile. Due to the distinct operational attributes of the ASBM threat, the unique 
functionality of the ASBMD System will be limited to the tracking and elimination of these 
threats during the post-boost phase of flight. Although the threats will be tracked throughout 
their flight by remote and onboard sensors, the engagement of the threats will not occur until 
post-boost phase. 
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2 NOTIONAL ARCHITECTURE 


Figure C-1 depicts the high level notional architecture of the ASBMD System that will be 
used to eliminate the defined threats. Each of the key functions identified will be discussed in 
detail in later sections of this document. 



Figure C-1. Notional Functional Diagram 
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3 GENERATION OF SYSTEM REQUIREMENTS 

Figure C-2 depicts the general flow that was used to create the high-level functional 
requirements, Measures of Effectiveness (MOEs), and Measures of Performance (MOPs) for the 
ASBMD System. As depicted, the process began with definition of the initial needs statement; 
the team then created a general set of system requirements to address the capabilities that a 
system would need to fulfill in order to address the needs statement. The next step was to create 
a CONOPS to help bound the high-level system requirements in an operational context, which 
leads directly into development of MOEs and MOPs for the system. Each of these products is 
identified below. 



Figure C-2. Requirements Generation Process Flow 
3.1 Functional Requirements 

The following is a list of high-level functional requirements that was used to perform the 
follow-on system analysis and decomposition into the functional architecture shown in 
Figure C-1. This is an excerpted list of requirements provided as part of the CONOPS, and 
should not be viewed as a complete list of requirements that the system must meet. 

1) ASBMD System shall be capable of sending, receiving, and processing intelligence 
reporting messages to be used for situational awareness related to Ballistic Missile 
flight path. (Includes, but is not limited to, the ability to receive and process Global 
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Command and Control System Maritime [GCCSM], Link-16 Tactical Digital 
Information Link [TADIL-J], N-Series messages, and J-Series messages) 

2) ASBMD System shall process received intelligence messages and create radar search 
sectors to be used by both on-board and off-board sensors. 

3) ASBMD System shall track ballistic missiles including no less than 10 vehicles 
during midcourse and/or terminal phase of missile flight path. Tracking shall include 
the production and dissemination of engagement quality data. 

4) ASBMD System shall be capable of near simultaneous engagement of no-less-than 2 
ballistic vehicles. 

5) ASBMD System shall be capable of performing launch on remote using fire control 
quality data from the BMDS network. 

6) ASBMD System shall have the ability to perform both self-defense and Ballistic 
Missile Defense (BMD) missions. 

7) ASBMD System shall have a Mean Time Between Failures (MTBF) that is greater 
than or equal to the MTBF of the existing BMDS architecture into which the ASBMD 
System has been integrated. 

8) ASBMD System shall have the ability to perform high fidelity object discrimination. 

9) ASBMD System shall have the ability to perform localization. 

10) ASBMD System shall have the capability to perform threat identification. 

3.2 MOEs and MOPs 

The key ASBMD System MOEs and MOPs are identified below. As with the System 
Requirements before, these lists should not be considered complete, since they are meant to be 
excerpts that were used to help bound the system. 

3.2.1 MOEs 

1) Probability of detection 

2) Probability of false alarm 

3) Probability of kill 

4) Probability of correct identification 

5) Probability of correct discrimination 
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6) Maximum number of targets engaged 

7) Probability of information exchange 

8) Maximum number of targets simultaneously tracked 

3.2.2 MOPs 

1) Track formulation time 

2) Organic detection time 

3) Mean time to discriminate 

4) Engagement time 

5) Re-engagement time 

6) Time to conduct kill assessment 

7) Number of simultaneous engagements 

8) Number of non-detections 
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4 CAPABILITIES AND FUNCTIONAL DECOMPOSITION 

As originally depicted in Figure C-1, the notional functional decomposition contains key 
functions that are needed to ensure that the ASBMD System can meet its key mission 
requirements. This section of the Initial Capabilities Document (ICD) will decompose each of 
the high level functions to a lower level which will allow easier and more detailed mapping of 
each function to the defined functional requirements. A basic definition of each high-level 
function is provided below. The definition will help frame the expectations and flow of each of 
the decomposition diagrams. 

4.1 System Components and Functions 

The key system components and functions are defined below. 
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4.1.1 Search 

The basic flow of the Search function is depicted in Figure C-3, and is started upon the 
receipt of a queuing signal from either an off-board source (BMDS) or the human operator. The 
queuing parameters are then converted to radar parameters that are used to build the sector of 
space that will be searched. After calculation of the radar parameters and required resources, the 
system will then evaluate the ability to perform the requested search function with organic 
resources. At this point in the functional flow the system will take one of two actions, either it 
will determine organic resources are available and it will carry out the search function, or if it is 
determined that organic resources are not available, the system will then wait for remote search 
data from the BMDS that will be passed to the tracking function. From this point on in both this 
document and future documents this type of track data transfer will be called Launch on Remote 
(LoR). 



O 

<o 


I 

o 


Figure C-3. Search Function 
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4.1.2 Detect 

The Detect function is shown in Figure C-4. The Detect function is started when search 
results are received from either organic or remote sensors. The results from the search function 
are compared against the current file of existing objects and the system determines if the any of 
the attributes are either new or have changed. If changes or new objects are noted, the location 
information is sent to the Classify function. 


Detect Function 



Figure C-4. Detect Function 
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4.1.3 Classify 

The Classify function is shown in Figure C-5. The Classify function receives object 
attributes from the Detect function and compares them against algorithms to determine if they 
represent ballistic or non-ballistic objects. Upon determination of the classification of the objects, 
the Classify function updates the object attributes including the identification and passes the 
information to the Track function. 


Classify Function 



Figure C-5. Classify Function 
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4.1.4 Track 

The Track function is shown in Figure C-6. The Track function receives objects from the 
Classify function and computes the object trajectory. After determining and updating the track 
attributes, the track file is updated and stored. The updated tracking data is sent to the 
Discrimination function. 


The Track function is key to the ability of the ASBMD System and is independent of all 
other functions of the system. The Track function can be executed using remote or organic track 
data within the ASBMD System. Compilation of the object trajectory will be used to help 
determine the ability of the system to engage the object. 


Track Function 



Figure C-6. Track Function 
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4.1.5 Discriminate 

The Diseriminate function is shown in Figure C-7. The Discriminate function receives 
track data from the Track function and evaluates them against predetermined discrimination 
algorithms. The output of the evaluations will be the identification of the number of lethal 
objects in the current track gate. If the output of the evaluation determines that there are more 
lethal objects than previously known, the Discrimination function will notify the Track function 
of new objects to be tracked. If the output of the evaluation determines no new objects, the 
Discrimination function will update the attributes of the existing tracks and report back to both 
the Track and Engage functions. 


Discrimination Function 



Figure C-7. Discriminate Function 
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4.1.6 Engage 

The Engage function is shown in Figure C-8. The Engage function receives track 
information from the Discrimination function and, upon operator initiation, will compute and 
disseminate the fire control solution for the selected target. After operator approval, the weapon 
will be deployed and the Engage function will compute and carry out the guidance and kill 
assessment portion of the engagement. The Engage function is also responsible for creating and 
communicating the current status of the engagement to the larger BMDS. 


Engage Function 



Figure C-8. Engage Function 
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5 CONCLUSION 


The updated System Functional flow diagram is shown in Figure C-9. It is simplified, but 
shows the key flow of information that the ASBMD System must have to complete the intended 
mission. 



Figure C-9. System Flow 
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ABBREVIATIONS AND ACRONYMS 


ASBM 

Anti-Ship Ballistic Missile 

ASBMD 

Anti-Ship Ballistic Missile Defense 

dB 

Decibel(s) 

EO 

Electro-Optical 

ft 

Eoot/Eeet 

GBR-P 

Ground Based Radar Prototype 

IR 

Infrared 

KM 

Kilometer(s) 

m 

Meter(s) 

RCS 

Radar Cross Section 

s 

Second(s) 

W 

Watt(s) 
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Probability of Detection analysis was performed for of each of the four 
systems/elements that were evaluated to fulfill the search and detection functions. 


Table D-1. Values for Calculation of Minimal Detection Range 
and Probability of False Alarm 






SPY-1 

SPY-3 

Cobra Judy 

GRB-P 


P peak 

Power Transmitted by radar 

kw 

4000 

4500 

7000 

8000 


G 

Antenna Power Gain 

Unitiess 

316.227 

330 

370 

375 


Ae 

Antenna effective area 

m''2 

20 

22.64 

25 

20 


a 

Radar Cross Section (RCS) 

m''2 

1 

1 

1 

1 

6000 

R 

Distance from radar site to target 

km 

6000 

6000 

6000 

6000 

0.00 

Smin 

Minimai Signai Detection or Threshoid 


0.003 

0.004 

0.004 

0.004 

0.002 

N 

Noise Signai 


0.002 

0.002 

0.002 

0.002 

1 

Pf 

Probabiiity of Raise aiarm 


0.188776089 

0.166952249 

0.121390393 

0.1263174 


Table D-2. Values for Probability of False Alarm vs. Range 


SPY-1 

SPY-3 

Cobra Judy 

GBR-P 

Pf 

Range 

Smin 

Pf 

Range 

Smin 

Pf 

Range 

Smin 

Pf 

Range 

Smin 

4.53E-05 

1000 

0.020006 

2.16548E-05 

1000 

0.021480569 

3.2E-06 

1000 

0.025305 

4.06E-06 

1000 

0.024827 

0.006727 

2000 

0.010003 

0.004653469 

2000 

0.010740285 

0.0017888 

2000 

0.012652 

0.002016 

2000 

0.012414 

0.035636 

3000 

0.006669 

0.027873054 

3000 

0.00716019 

0.0147356 

3000 

0.008435 

0.015956 

3000 

0.008276 

0.08202 

4000 

0.005002 

0.068216339 

4000 

0.005370142 

0.0422938 

4000 

0.006326 

0.044895 

4000 

0.006207 

0.13525 

5000 

0.004001 

0.116710715 

5000 

0.004296114 

0.0796198 

5000 

0.005061 

0.083513 

5000 

0.004965 

0.188776 

6000 

0.003334 

0.166952249 

6000 

0.003580095 

0.1213904 

6000 

0.004217 

0.126317 

6000 

0.004138 
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Figure D-1. Analysis of Probability of False Alarm vs. Range 


Minimum Detection Signai vs Range 



Range to Target, KM 



-SPY-1 


SPY-3 

-A- 

- Cobra Judy 


GBR-P 


Figure D-2. Analysis of Probability of Detection vs. Range 
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Equation (D-1) provides the calculation of affective aperture size: 



51020 ( 0 . 3 )^ 


(D-1) 


Equation (D-2) provides the calculation of maximum detection range: 


PpeakGoA, 
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Table D-3. Calculation of Maximum Detection Range 
vs. Radar Cross Section (RCS) 


SPY1 

SPY 3 

Cobra Judy 

GBR-P 

Peak Power 

4000000 

Watts 

Peak Power 

4500000 

Watts 

Peak Power 

7000000 

Watts 

Peak Power 

8000000 

Watts 

Gain 

316227 

w/w 

Gain 

330000 

w/w 

Gain 

370000 

w/w 

Gain 

375000 

w/w 

Ae 

20 

m''2 

K 

22.64 

m''2 

Ae 

25 

m''2 

Ae 

20 

m''2 

Smin 

0.03 

w/w 

Smin 

0.005 

w/w 

Smin 

0.004 

w/w 

Smin 

0.005 

w/w 

Wavelength 

0.03 

m 

Wavelength 

0.03 

m 

Wavelength 

0.03 

m 

Wavelength 

0.03 

m 





RSCdB 

RSC W 

Range 

KM 

RSC dB 

RSC W 

Range 

KM 

RSCdB 

RSC W 

Range 

KM 

RSCdB 

RSC W 

Range 

KM 

1 

1.26 

1611 

1 

1.26 

2706 

1 

1.26 

3371 

1 

1.26 

3128 

2 

1.58 

1704 

2 

1.58 

2864 

2 

1.58 

3567 

2 

1.58 

3310 

4 

2.51 

1913 

4 

2.51 

3215 

4 

2.51 

4005 

4 

2.51 

3716 

6 

3.98 

2147 

6 

3.98 

3608 

6 

3.98 

4494 

6 

3.98 

4170 

8 

6.31 

2409 

8 

6.31 

4049 

8 

6.31 

5043 

8 

6.31 

4679 

10 

10 

2703 

10 

10 

4543 

10 

10 

5658 

10 

10 

5250 


Search/Detection Range vs RCS 



Search Range (KM) 


Figure D-3. Maximum Detection Range vs. RCS 
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Table D-4. Values for Power-In vs. Range 


Ae = 

1m''2 

P = 

2000 w 





Range 

Pin 

0 

0 

200 

0.003979 

400 

0.000995 

600 

0.000442 

800 

0.000249 

1000 

0.000159 

2000 

3.98E-05 

3000 

1.77E-05 

4000 

9.95E-06 

5000 

6.37E-06 

6000 

4.42E-06 

7000 

3.25E-06 

8000 

2.49E-06 

9000 

1.96E-06 
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Figure D-4. Formula for Power-In vs. Range 



Figure D-5. Power-In vs. Range for EO/IR Sensor 
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Table D-5. Power-In vs. Range for EO/IR Sensor 


Target Surface Area = 

3 

m''2 

Target 

Surface 

Area 

Range 

Pin 

Emissivity = 

0.95 


0.5 

7035.407 

3.22E-06 

Temperature = 

500 

K 

1 

9949.568 

1.61E-06 

Effective Aperture = 

1 

m^2 

1.5 

12185.68 

1.07E-06 

Frequency Band = 

2-6 urn 


2 

14070.81 

8.04E-07 

Smin — 


0.0000006 

w 

2.5 

15731.65 

6.43E-07 

p = 


2000 

w 

3 

17233.16 

5.36E-07 





3.5 

18613.94 

4.59E-07 





4 

19899.14 

4.02E-07 





4.5 

21106.22 

3.57E-07 





5 

22247.91 

3.22E-07 





5.5 

23333.8 

2.92E-07 
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Equation (D-3) provides the calculation of maximum range for the EO/IR sensor: 


R 


max 




S(7 




4;riS’ 


null 


(D-3) 



Figure D-6. Power Target Size and Power-In vs. Detection Range 
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The team performed operational analysis consisting of the operational range 
capabilities of the platform. This is the range that the host platform can maneuver away 
from the defended asset and still be able to defend it if fired upon. The analysis is highly 
dependent on the capabilities of the interceptor that is used against the threat. 


Table D-6. Calculation of Maximum Interceptor Launch Range 

vs. Interceptor Speed 


Max Interceptor 
Launch Range (km) 

Interceptor Speed 
(km/s) 

Z range 

X/Y Range 

480 

1.2 

50.00 

430.00 

640 

1.6 

50.00 

590.00 

640 

1.6 

50.00 

590.00 

800 

2 

50.00 

750.00 

960 

2.4 

50.00 

910.00 

1120 

2.8 

50.00 

1070.00 

1200 

3 

50.00 

1150.00 

1360 

3.4 

50.00 

1310.00 

1520 

3.8 

50.00 

1470.00 

1600 

4 

50.00 

1550.00 

Conversion Units: 

ft 

meters 

miles 

km 

5280 

1655.172414 

1 

1.655172414 

160000 

50156.73981 

30.3030303 

50.15673981 

Assumptions: Exoatmosphere = > 160K ft or 50 km 

Total Target Flight Time = 420 sec Target flight time to re-entry = 403 sec 

Organically Tracked 3 sec after liftoff Reaction time + interceptor flyout 400 sec 

Target Speed = 3 km/s Constant interceptor speeds 
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Figure D-7. Power Maximum Operating Range vs. Interceptor Speed 



Cross Range (km) 


•1.2 m/s 

• 2 m/s 

• 3 m/s 
•4 m/s 


Figure D-8. Maximum Operational Range for Host Platform 
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The team performed a Data Covariance Analysis to determine the effects of 
integrating systems that output filtered data. This analysis also shows the effects of 
filtered data on a system that is designed to use unfiltered raw data. The analysis confirms 
that trying to combine multiple sources of filtered data can produce an outcome that is 
less useful than if the system uses a single source of data. 


Table D-7. Calculation of Data Covariance for Filtered and Non-Filtered Sources 


Time 

Source 

1 

Track 

Points 

1 

Covariance 

Source 

2 

Track 

Points 

2 

Covariance 

2 

Filtered 

Filtered 

Track 

Points 

Filtered 

Covariance 

1 

10 

12 

2 

20 

22 

2 

15 

22 

7 

2 
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Figure D-9. Maximum Operational Range for Host Platform 



Figure D-10. Effects of Filtering Data on Accuracy 
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ABBREVIATIONS AND ACRONYMS 


ASBM 

Anti-Ship Ballistic Missile 

ASBMD 

Anti-Ship Ballistic Missile Defense 

BMD 

Ballistic Missile Defense 

CONOPS 

Concept of Operations 

dB 

Decibel(s) 
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Design Reference Mission 

DRMP 

Design Reference Mission Profile 

EO 

Electro-Optic 

GBR-P 

Ground-Based Radar-Prototype 

ICD 

Initial Capabilities Document 

IR 

Infrared 

km 

Kilometer(s) 

km/h 

Kilometer(s) per hour 

m 

Meter(s) 

MW 

Megawatt(s) 

Pd 

Probability of Detection 

PRE 

Pulse Repetition Erequency 

RCS 

Radar Calculation Sheets 
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Analysis of Alternatives Artifacts 



Figure E-1. ASBMD Analysis of Alternatives Process 
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Table E-1. Key Functional Attributes 


Analysis 

Area 

Recommended Attribute Analysis 


Search Rate (Scan Rate) 

Search 

Search Volume Capabilities 

Range 


Angular Resolution 


Signal-to-Noise Ratio 

Detection 

False Alarm Rate 

Probability of Detection (Adjusting Target and Environmental Attributes) 


Radar Range Calculation for Maximum Detection Range 


PRF and Tracking Errors 

Tracking 

Effective Aperture and Resolution Calculations 

Effects of Tracking Ranges Given Tracking and Turning Gate Changes 


Transition-to-Track Timeline Analysis 

Intercept 

Variants 

General Systems Capability Analysis 

Kill Timeline Analysis by Varying Range 

Maximum Effective Ranges 
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Table E-2. System Comparison (Search/Detection) 


Function Name (Search/Detection) 

Options 

Performance Parameters 

Requirements 

Pros / Cons 

Max 

Range/ 

Accuracy 

Max 

Power 

Ae 

(Effective 

Aperture 

Size) 

Smin 

SPY-1 B(D) 

* 1460 km 

3 MW 

20m''2 

-13dB 

ASBMD System shall be capable 
of searching a designated search 
sector of not less than 30 degrees 
at a distance of not less than 750 
km in less than 2 seconds, when 
cued by either off board 
intelligence or the onboard 
operator. 

Pro: Mature, proven system capability 

Con: Shorter maximum range limits the 
maneuverability options of the Fleet 
Con: Heavily reliant on intelligence data to 
allow for resource focusing 

SPY-3 

** 2527 km 

4.5 MW 

23m''2 

-23dB 

ASBMD System shall be capable 
of searching a designated search 
sector of not less than 30 degrees 
at a distance of not less than 750 
km in less than 2 seconds, when 
cued by either off board 
intelligence or the onboard 
operator. 

Pro: Greater search range and accuracy 
capabilities than the SPY-1 

Pro: Greater peak power and Ae size 
allows for search and detection of 
smaller RCS 

Con: Unproven system that is still under 
development 

Con: Power usage to excite radar elements 
exceeds that of current ship 
capabilities 

Con: Unable to uplink with current weapon 
inventory 

Cobra Judy 

** 2681 km 

7 MW 

26.4m''2 

-20dB 

ASBMD System shall be capable 
of searching a designated search 
sector of not less than 30 degrees 
at a distance of not less than 750 
km in less than 2 seconds, when 
cued by either off board 
intelligence or the onboard 
operator. 

Pro: Greatly Increases search and 
detection ranges 

Pro: Allows greater operational 
maneuverability 

Con: Large power consumption 
requirements 

Con: Unable to control current engagement 
weapons 

Con: Too large to fit onto current 
operational naval vessels 

GBR-P 

** 3297 km 

8 MW 

20.4m''2 

-23dB 

ASBMD System shall be capable 
of searching a designated search 
sector of not less than 30 degrees 
at a distance of not less than 750 
km in less than 2 seconds, when 
cued by either off board 
intelligence or the onboard 
operator. 

Pro: Increased search and detection 
ranges 

Pro: Increases operational capability of 
fleet 

Con: Power consumption is too large 

Con: Weight and size is restrictive 

Con: RCS signature much too large for 
naval vessel 

Con: No weapon control capability 

All calculations assume 30 degree search sector. 

* Derived from Aegis BMD briefing. 

** See specific Radar Calculation Sheets. 
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Table E-3. Function Name (Track) 


Function Name (Track) 

Options 

Performance Parameters 

Requirements 

Pros / Cons 

Max 

Range/ 

Accuracy 

Max 

Power 

Ae 

(Effective 

Aperture 

Size) 

Smin 

SPY-1 B(D) 

* 1460 km 

3 MW 

20m''2 

-13dB 

ASBMD System shall be 
capable of tracking no less 
than 2 simultaneous 
ballistic missiles at a 
distance of not less than 

750 km. 

Pro: Mature, proven system capability 

Con: Shorter maximum range limits the 
maneuverability options of the Fleet 

Con: Heavily reliant on intelligence data to 
allow for resource focusing 

SPY-3 

** 2527 km 

4.5 MW 

23m''2 

-23dB 

ASBMD System shall be 
capable of tracking no less 
than 2 simultaneous 
ballistic missiles at a 
distance of not less than 

750 km. 

Pro: Greater search range and accuracy 
capabilities than the SPY-1 

Pro: Greater peak power and Ae size allows 
for search and detection of smaller 

RCS 

Con: Unproven system that is still under 
development 

Con: Power usage to excite radar elements 
exceeds that of current ship capabilities 
Con: Unable to uplink with current weapon 
inventory 

Cobra Judy 

** 2681 km 

7 MW 

26.4m''2 

-20dB 

ASBMD System shall be 
capable of tracking no less 
than 2 simultaneous 
ballistic missiles at a 
distance of not less than 

750 km. 

Pro: Greatly Increases search and detection 
ranges 

Pro: Allows greater operational 
maneuverability 

Con: Large power consumption requirements 

Con: Unable to control current engagement 
weapons 

Con: Too large to fit onto current operational 
naval vessels 

GBR-P 

** 3297 km 

8 MW 

20.4m''2 

-23dB 

ASBMD System shall be 
capable of tracking no less 
than 2 simultaneous 
ballistic missiles at a 
distance of not less than 

750 km. 

Pro: Increased search and detection ranges 
Pro: Increases operational capability of fleet 
Con: Power consumption is too large 

Con: Weight and size is restrictive 

Con: RCS signature much too large for naval 
vessel 

Con: No weapon control capability 

EO/IR 

9.9 km 

N/A 

1m''2 

0.0000006 w 

ASBMD System shall be 
capable of tracking no less 
than 2 simultaneous 
ballistic missiles at a 
distance of not less than 

750 km. 

Pro: Small complex system 

Pro: Very accurate {< 2 m error at maximum 
range) 

Con: Unable to only integrate with existing 
systems 

Con: Maximum usage is very restrictive for 
high altitude threat 

Con: Requires external preloading 

commands (no automated search 
capability) 

All calculations assume 30 degree search sector. 

* Derived from Aegis BMD briefing. 

** See specific Radar Calculation Sheets. 
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Table E-4. Function Name (Engage) 


Function Name (Engage) 

Options 

Performance Parameters 

Requirements 

Pros / Cons 

Max 

Effective Range 

Max Closure Speed 

SPY-T 

167 km 

3186 km/h 

ASBMD System shall be capable 
of near simultaneous engagement 
of no-less than 2 ballistic vehicles. 

Pro: Currently in production 

Pro: Flight test data available to prove 
time and PK 

Con: Max range limits intercept too close to 
or within atmosphere 

SPY-3 

245 km 

4248 km/h 

ASBMD System shall be capable 
of near simultaneous engagement 
of no-less than 2 ballistic vehicles. 

Pro: 

Con: 

Rail Gun 

400 km 

7430 km/h 

ASBMD System shall be capable 
of near simultaneous engagement 
of no-less than 2 ballistic vehicles. 

Pro: Greater range than conventional 
weapons 

Pro: Greater closure speeds increasing 
accuracy due to less time for target to 
maneuver 

Pro: Ten shots per minute allow for 
multiple shots and multiple 
engagements in short time 

Con: Inability to modify flight path, very 
ineffective against fast moving 
maneuvering threats 

Con: Fleat and power requirements may 
exceed capabilities of current fleet 

Directed 

Energy 

System 

375 km 

N/A 

ASBMD System shall be capable 
of near simultaneous engagement 
of no-less than 2 ballistic vehicles. 

Pro: Virtually zero delay between firing 

and hitting target which eliminates the 
effects of moving targets. 

Con: Very fragile aiming and firing systems 
Con: Blooming effects cause the 

breakdown of the beam at distances 
greater than 300 km 

* Closure speed calculated at > 40 K feet 

** Rail Gun range based on theoretical values derived from data collected during 2008 Navy firings. 
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Figure E-2. Gross System Model 
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Figure E-3. Detailed System Model 
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Figure E-4. Functional Sub-Model Breakout Example 
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ABBREVIATIONS AND ACRONYMS 


AoA 

Analysis of Alternatives 

ASBMD 

Anti-Ship Ballistic Missile Defense 
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Concept of Operations 

DoD 

Department of Defense 
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Initial Capabilities Document 
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In-Process Review 
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Measure of Effectiveness 
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Risk Management Guide 

SSP 

Strategic Systems Programs 
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1 OVERVIEW 

Risk is defined in the Risk Management Guide (RMG) for Department of Defense 
(DoD) Acquisition (DoD, 2006, August) as being “a measure of future uncertainties in 
achieving program performance, goals, and objectives within defined cost, schedule, and 
performance constraints.” Unfortunately, both technical and programmatic risks are an 
inevitable fact of system development. Identifying and planning the strategies to mitigate 
these risks before they become issues is an important part of a successful systems 
engineering process. For this risk management process to be effective, it must be 
addressed throughout the entire system development process by the technical team and 
program management team. 

The DoD RMG provides a risk management process model that can be used (or 
tailored, as necessary) to manage risk throughout the system acquisition process. This 
approach to managing risk was chosen by the Anti-Ship Ballistic Missile Defense 
(ASBMD team). Figure 1-1 shows the key activities for this risk management process. 


Risk 

Identification 



Risk 

Analysis 


Risk 

Tracking 




Risk 

Mitigation 

Planning 



% ^ 


Risk 

Mitigation 

Plan Implementation 


Figure F-1. DoD Risk Management 
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2 RISK IDENTIFICATION AND ANALYSIS 


The first step in the DoD risk management process is risk identification. The 
purpose of this activity is to identify what could go wrong that would prevent the system 
development from succeeding. The next activity is to analyze the risks that have been 
identified. Risks can be described as having three components: 


• Root cause, which, if avoided, would prevent an issue from occurring 

• Likelihood that this root cause will occur 

• Consequence of this occurrence 

Each root cause must be assessed as to the likelihood of it occurring and the 
consequence to the program development if it was to occur. The DoD RMG categorizes 
three types of risk that could adversely impact the success of a system acquisition: 
technical, schedule, and cost. The DoD RMG also provides a standard format for a matrix 
that may be used to evaluate and report the results of the risk analysis phase. This Risk 
Reporting Matrix is shown in Figure F-2. The level of risk for each root cause is 
represented as low (green cells), moderate (yellow cells), or high (red cells). 


o 

o 


JS 







Consequence 


Figure F-2. Risk Reporting Matrix 
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Guidelines are provided in the DoD RMG for assigning the specific level, 

1 through 5, for the likelihood and consequence of each root cause. The level definitions 
provided in the DoD RMG were evaluated and accepted for use by the ASBMD team 
when analyzing the risks for the system architecture development effort. Table F-1 lists 
the definitions provided in the DOD RMG that correspond to each level of the likelihood 
and probability of the occurrence of a risk’s root cause. 

Table F-1. Likelihood Level Criteria 


Level 

Likelihood 

Probability of Occurrence 

1 

Not Likely 

~ 10% 

2 

Low Likelihood 

~ 30% 

3 

Likely 

~ 50% 

4 

Highly Likely 

~ 70% 

5 

Near Certainty 

~ 90% 


Table F-2 lists the definitions which have been paraphrased from the DoD RMG 
for use by the ASBMD team for each level of consequence if a risk’s root cause were to 
occur. Level definitions are provided for each level of the three risk categories. 
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Table F-2. Consequence Level Criteria 


Level 

Technical 

Schedule 

Cost 

1 

Minimal or no consequence to 
technical performance 

Minimal or no impact 

Minimal or no impact 

2 

Minor reduction in technical 
performance or supportability, can be 
tolerated with little or no impact on 
program 

Able to meet key dates 

Budget increase or unit 
production cost 
increase 
(< 1% of budget) 

3 

Moderate reduction in technical 
performance or supportability with 
limited impact on program objectives 

Minor schedule slip; 
able to meet key 
milestones with no 
schedule float 

Budget increase or unit 
production cost 
increase 
(< 5% of budget) 

4 

Significant degradation in technical 
performance or major shortfall in 
supportability; may jeopardize 
program success 

Program critical path 
affected 

Budget increase or unit 
production cost 
increase 

(< 10% of budget) 

5 

Severe degradation in technical 
performance; cannot meet KPP or key 
technical/supportability threshold; will 
jeopardize program success 

Cannot meet key 
program milestones 

Exceeds Acquisition 
Program Baseline 
threshold 
(> 10% of budget) 
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3 RISK MITIGATION PLANNING AND TRACKING 

The next steps in the risk management process involve mitigation planning. These 
activities identify and evaluate the options available to eliminate, or at least reduce, the 
risks that could jeopardize the success of the system architecture development effort. 
Successful mitigation plans are specific as to what needs to be done, when it needs to be 
done, and who is responsible for doing it. The method chosen by the ASBMD team for 
documenting risk mitigation plans is an adaptation of the template created by the 
Strategic Systems Programs (SSP), SP23 Fire Control Section, for use in managing the 
risks associated with the development of its weapon control systems. A blank copy of this 
template is shown in Figure F-3. 


Risk: 


OsscriDtion: 


Status: 


Context: 


Other 

Branches/Orgs 

Effected: 


Assign«d to: 



Mtigatlon Plan 

Step 

Planned 

Completion 

Actual 

Completion 

Status 

Risk State 
when done 





































Exit Criteria 







Figure F-3. ASBMD Risk Mitigation Plan Template 

The last activity of the risk management process adopted by the ASBMD team is 
risk tracking. The ASBMD team completed regular reviews of the identified risks and 
their associated mitigation plans as part of a regular weekly team meeting. 

The most important aspect of this, or any, risk management process is that it is 
continuous and needs to be revisited, iteratively, until the system development has been 
successfully completed. This aspect of risk management was also adopted by the 
ASBMD team and regular reviews of risk included the identification of any 
new/emerging risk root causes. As new risks were identified, mitigation plans were 
created and regularly reviewed. 
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4 ASBMD PROJECT AND SYSTEM RISKS 


The ASBMD team had two primary areas of risk that were identified and tracked. 
One area was project management-related and encompassed the risks associated with 
successfully completing this Capstone Project. The risk reporting matrix for project 
management risks is shown in Figure F-4. Table F-3 summarizes these project 
management risks and includes an identifier used to track the risk, a description of the 
root cause, and the status of the risk at the time of the Capstone In-Process Review 
(IPR) #2. 


5 

1 4 

o 

X. 

"3 3 

2 
1 

1 2 3 4 5 

Consequence 



Figure F-4. ASBMD Project Management Risk Matrix (as of IPR #2) 
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Table F-3. ASBMD Project Management Risk Summary (as of IPR #2) 


Risk ID 

Description 

Status 

P1 

Team will not be able to generate a list of viable alternatives in a timely 
manner. 

Closed 

P2 

The team will not decide on a list of Key Performance Parameters 
(KPPs) in a timely manner.) 

Closed 

P3 

Modeling and simulation tools will not be developed in time for use in 
the Analysis of Alternatives (AoA). 

Improving 

P4 

Final project report will not be completed on time. 

No change 

P5 

Team will not be able to identify viable candidate systems to support 
the AoA process.) 

Closed 


The second area of risk was related directly with the technical challenges of 
developing the ASBMD system itself. The risk reporting matrix for system engineering 
risks at the time of the IPR #2 is shown in Figure F-5. Table F-4 provides a summary of 
these systems engineering risks. 



Consequence 


Figure F-5. ASBMD System Engineering Risk Matrix (as of IPR #2) 
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Table F-4. ASBMD System Engineering Risk Summary (as of IPR #2) 


Risk ID 

Description 

Status 

S1 

The chosen solution is not able to be integrated with existing 
systems. 

Improving 

S2 

The test agency will need to acquire a functionally 
representative threat target to test the proposed ASBMD 
system. 

No change 

S3 

Necessary resources must be planned and allocated to backfit 
the system solution(s) into the Fleet. 

No change 


Risk mitigation plans were developed for each of these risk root causes and were 
tracked by the ASBMD team. Tables F-5 through F-12 show the mitigation plan for each 
of these risks at the time of the second IPR briefing. Since the second IPR, the ASBMD 
team has continued its work and its commitment to risk management. All risks have been 
mitigated to ensure the successful completion of our Capstone Project. 


202 










Appendix F 


Table F-5. Risk Mitigation Plan for Risk PI 


Risk: 

PI : The team will not be able to generate 
a list of viable alternatives to counter the 
threat in a timely manner, so the analysis 
of alternatives will be delayed. 


Description: 

Research still needs to be done by the 
team members to narrow the scope on 
what the threat is and what is needed to 
combat that threat. This will be a 
challenge with individual work schedules, 
travel schedules, and personal 
commitments. 

Status: 

Closed 

Context: 

Scope, schedule, and resource planning 

Other 

Branches/Orgs 

Effected: 

Stakeholders 

Assigned to: 

Team 1 

Mitigation Pian 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk State 
when done 


1) Discuss research progress at weekly 
team meetings. 

1-May-09 

15-Aug-09 


Y 

2) Plan milestones and track progress on 
the team schedule for the definition of 
alternatives to consider. 

1-May-09 

15-Aug-09 


Y 

3) Perform research to define the scope 
of the threat we are addressing. 

15-May-09 

30-Jun-09 


Y 

4) Perform research to investigate any 
existing systems that may be used for 
the ASBMD architecture. 

31-JUI-09 

15-Aug-09 


G 

5) Generate list of alternatives for further 
analysis. 

31-Jul-09 

15-Sep-09 

Close Risk 


Exit Criteria 

Team consensus on what the ASBMD 
system needs to do and a list of viable 
alternatives that could be used to 
implement it. 
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Table F-6. Risk Mitigation Plan for Risk P2 


Risk: 

P2: The team will not decide on a list of 
KPPs in a timely manner, so analysis of 
alternatives will be delayed. 


Description: 

There will be many choices for MOEs 
and MOPs. The team will need to select 
only a few for use as KPPs and come to 
an agreement on what these should be. 
Plus, there is always the challenge of 
individual work schedules, travel 
schedules, and personal commitments. 

Status: 

Closed 

Context: 

Scope, schedule and resource planning 

Other 

Branches/Orgs 

Effected: 

Stakeholders 

Assigned to: 

Team 1 

Mitigation Pian 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk State 
when done 


1) Designate a lead for the KPP 
selection. The lead will keep the effort 
on track and direct work on the task. 

1-May-09 

1-May-09 

Lead is 
Mike 
Roberts 

Y 

2) Plan milestones and track progress on 
the team schedule associated with 
MOE/MOP evaluation and KPP 
selection. 

1-Aug-09 

15-Aug-09 


Y 

3) Decide what MOEs/MOPs are desired 
and investigate what data is available. 

15-Aug-09 

15-Aug-09 


G 

4) Generate list of KPPs to use for the 
analysis of alternatives. 

31-Aug-09 

30-Aug-09 

Close Risk 


Exit Criteria 

Team consensus on the ASBMD system 
KPPs. 
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Table F-7. Risk Mitigation Plan for Risk P3 


Risk: 

P3: Modeling and simulation tools will 
not be developed in time for their use in 
the analysis of alternatives. 


Description: 

Because of competing individual work 
schedules, travel schedules, and 
personal commitments, the 
development of tools to analyze 
alternatives is delayed. This also might 
occur if other project risks are not 
properly or fully mitigated. 

Status: 

Closed 

Context: 

Schedule and resource planning 

Other 

Branches/Orgs 

Effected: 

Stakeholders 

Assigned to: 

Team 1 

Mitigation Pian 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk State 
when done 


1) Designate a lead for the model and 
simulation development. The lead 
will keep the effort on track and 
direct work on the task. 

1-May-09 

22-May-09 


Y 

2) Plan milestones and track progress 
on the team schedule associated 
with tool development. 

1-Jun-09 

31-Aug-09 


Y 

2(a) Perform modeling proficiency 
demonstration. 

15-Jun-09 

12-Jun-09 


G 

3) Come to an agreement on what tools 
are needed. 

15-Jul-09 

1-Aug-09 


G 

4) Generate needed tools. 

15-Aug-09 

31-Aug-09 

Close Risk 


Note: Modeling Overview was delivered 
to advisors on 31-Aug-09. 





Exit Criteria 

Tools are available for use. 
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Table F-8. Risk Mitigation Plan for Risk P4 


Risk: 

P4: Final project report will not be 
completed on time. 


Description: 

Because of competing individual work 
schedules, travel schedules, and 
personal commitments, the writing of 
the project report and presentation is 
delayed. This also might occur if other 
project risks are not properly or fully 
mitigated. A lead for this task has 
already been chosen: Jeannie 

Hobgood. 

Status: 

Improving 

Context: 

Schedule and resource planning 

Other 

Branches/Orgs 

Effected: 

None 

Assigned to: 

Team 1 

Mitigation Pian 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk State 
when done 


1) Plan milestones and track progress 
on the team schedule for the project 
report and presentation. 

1-May-09 

on-going 


G 


2) Start the project report with 

information for chapters I and II and 
the PMP appendix at the end of the 
first quarter (Spring 2009). Also start 
the final project presentation slides. 

30-Jun-09 

6-JUI-09 

Released draft 
of Chap. 1 and 
have 

CONORS and 
ICD 

documents to 
use for other 
chapters 

G 

3) Update the project report and 
presentation with information 
available at the end of the second 
quarter (Summer 2009). 

1-Oct-09 

23-Oct-09 

Chap 3 
released for 
review and 
IPR#2 

G 

4) Complete chapter 4 and remaining 
sections (appendices, abstract, 
executive summary, etc). Assemble 
and release for final team review. 

20-Nov- 

09 



G 

5) Complete final report and submit for 
department review. 

30-Nov- 

09 


Close Risk 


Exit Criteria 

Correctly formatted report is submitted 
to Systems Engineering department. 
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Table F-9. Risk Mitigation Plan for Risk P5 


Risk: 

P5: The team will not be able to find 
feasible solutions to meet the stated 
need. 


Description: 

Although exhaustive research and 
analysis has been done, the team 
cannot recommend a solution that will 
resolve the problem statement. 

Status: 

Closed 

Context: 

Technical 

Other 

Branches/Orgs 

Effected: 

Stakeholders, Advisors 

Assigned to: 

Team 1 

Mitigation Pian 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk State 
when done 


1) Discuss research and analysis 
findings at team meetings. 

15-Jul-09 

15-Jul-09 


G 

2) Discuss alternatives and brainstorm 
ideas. 

1-Aug-09 

1-Aug-09 


G 

3) Generate table of alternative 
architectures for each functional 
area. 

15-Sep-09 

15-Sep-09 

Close Risk 


Exit Criteria 
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Table F-10. Risk Mitigation Plan for Risk SI 


Risk: 

SI : The chosen solution is not able to 
be integrated with existing systems. 


Description: 

Although exhaustive research and 
analysis has been done, the team 
cannot recommend a solution that will 
work with existing systems. 

Status: 

Improving 

Context: 

Technical 

Other 

Branches/Orgs 

Effected: 

Stakeholders, Advisors 

Assigned to: 

Team 1 

Mitigation Pian 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk State 
when done 


1) Discuss research and analysis 
findings at team meetings. 

15-Jul-09 

15-Jul-09 


Y 

2) Discuss alternatives and brainstorm 
ideas. 

15-Aug-09 

15-Aug-09 


Y 

3) Primary selection criteria for 

alternatives include interoperability. 

1-Sep-09 

1-Sep-09 


G 

4) Chosen architecture for system of 
systems supports interoperability. 

15-NOV-09 


Close Risk 


Exit Criteria 
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Table F-11. Risk Mitigation Plan for Risk S2 


Risk: 

S2: Development of Test Threat 
Simulator 


Description: 

The aim of this project is to eliminate a 
non-traditional threat that we currently 
have no technological equivalent of. 

The Test and Evaluation (T&E) Agency 
is going to have to develop an 
operationally representative threat to 
test the capability of any proposed 
system. 

Status: 

Improving 

Context: 

Technical 

Other 

Branches/Orgs 

Effected: 

T&E Agency & Program Office 

Assigned to: 

T&E Agency 

Mitigation Pian 

Step 

Planned 

Completion 

Actual 

Completion 

Status 

Risk State 
when done 


1) Make T&E and Program Office 
group aware of risk. 

15-Jul-09 

20-Jul-09 


G 

2) Monitor T&E plan development 
(include coverage in final report). 

15-NOV-09 


Close Risk 


Exit Criteria 
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Table F-12. Risk Mitigation Plan for Risk S3 


Risk: 

S3: Outfitting the Current DoD assets 
with Solution 


Description: 

The ability to "backfit" current 
hardware with a solution is historically 
a challenge. Identifying resources 
needed and implementing a plan are 
critical. 

Status: 

Improving 

Context: 

Financial, Programmatic 

Other 

Branches/Orgs 

Effected: 

Program Office, Resource Sponsor 

Assigned to: 

Program Office 

Mitigation Pian 

Step 

Planned 

Completion 

Actual 

Completion 

Status 

Risk State 
when done 


1) Identify required resources for 
backfit. 

1-Nov-09 

4-NOV-09 


Y 

2) Consider costs for those resources. 

15-NOV-09 

19-NOV-09 


G 

3) Address results in final report. 

20-NOV-09 


Close Risk 


Exit Criteria 
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